just be so much nicer if we didn't have to cd /etc/init.d/ ; ln -s net.lo net.eth0 and the like. udev could auto create these symlinks. there are a few other ways it could be done too. Reproducible: Always
sys-fs/udev is only supposed to populate /dev, right? Also, /etc/init.d/net.* is supposed to be used for static interfaces, whereas various implementations exist to dynamically configure interfaces (think networkmanager and alike).
well it could be done at build time even. I talked to roy (openrc) he basically suggested udev or maybe the dhcpcd... but the latter doesn't seem right. networkmanager is more for configuring interfaces not making them. I'm not aware of any laws that says udev can't populate other stuff if necessary. given it's primary job is dev. but if it makes a better user experience, why not.
udev does do other stuff, including triggering daemons to start (gpsd for eg). I don't see any problem with it just making the symlink.
udev net.sh has a name-based blacklist of device names to ignore. For all other stuff it then looks for an existing /etc/init.d/net.xxx else it aborts. This can be changed to create the symlink, yes. But I think it will also create unwanted symlinks. Second point: At udev startup time /etc/init.d is still readonly in most cases.
How should we react if /etc/init.d is not yet writable? The most advanced way would be to log the attempts and postpone it until udev-postmount runs, and let it create the links and re-run net.sh there to finally get baselayout/openrc run the scripts.
I personally don't think that net.xxx scripts are the right way to go, and openrc-0.5.0 will ship with "new net" functionality. This will be init scripts for daemons and static IP networking. Once that happens, but bug will become irrelevant. The basic idea is that one init script "network" will configure your static addresses and dynamic addressing will be handled by dhcpcd-5 (it can handle static addressing per interface/ssid also). Link/interface management will be handled by their specific scripts - wpa_supplicant, openvpn, etc. This works very well as dhcpcd-5 handles interface addition and removal as well as link carrier detection.
I'm inclined to NOT create these any more, since with newnet users won't want them at all. They are still good for oldnet users, but we cannot detect which is being used easily. base-system: votes?
This issue has been around for a while, but I am also inclined toward not creating the links because of the reasons mentioned here as well as the ones mentioned on the original bug. *** This bug has been marked as a duplicate of bug 186156 ***
