On Sunday 22 October 2006 03:08, Mike Frysinger wrote: > On Saturday 21 October 2006 10:05, Roy Marples wrote: > > baselayout-1.13 now handles multiple provides. That means that you have > > can 3 or more services that provide "logger" and baselayout will pick the > > right one based on what's running, then what's run the runlevel and > > finally alphabetical order. As such, our net scripts all provide "net". > > Handy that. > > > > RC_STRICT_NET_CHECKING is used in the init script depdency process, and > > quite frankly I'd like to punt it and replace it with ........... > > rc-update! Yes, just put the init scripts that "net" should provide in > > your runlevel. boot contains net.lo by default and we also coldplug any > > net devices by default too. > > you should outline how people would be able to get the existing behavior > ... simply saying the new baselayout handles multiple provides doesnt > exactly translate into RC_STRICT_NET_CHECKING no longer being needed > -mike
OK, from my persepective we had RC_STRICT_NET_CHECKING because we couldn't previously handle multiple provides. Here's how the new way translates. none - net is always up Well, this is now done by never having any net scripts in any runlevels. Kinda kludgy really as you need a loopback for quite a few things. lo - net is up if lo is up Just have net.lo in the boot runlevel - it should always be there anyway. yes - net is up if all net scripts in the runlevels are started. Same behaviour as before. Well, actually this is the new default. no - net is up if any interface except for lo is up This is the tricky one as we have effectively lost it, so try and follow my logic here. This is only really useful for people with >1 interface, namely wired, wireless or ppp and we don't actually know which interface we will be using - we don't even know if they will be on the same or different networks. In this instance, the actual net services will bind to 0.0.0.0, which is all interfaces available. So daemons themselves aren't the issue because if they need to bind to a specific IP or interface, then the interface that provides that should be in the same runlevel. So our only concern would be a service that uses the network, like nfsmount. But in this scenario, nfsmount is broken anyway as eth0 could be up on 1.2.3.4 and nfsmount works, then eth1 comes up on 5.6.7.8 and eth0 then stops. The net dependency is satisfied so nfsmount stays up even though it's obviously wrong. With "no", nfsmount would stop when eth1 stops, with the new way it just stays up. Of course, you can bind nfsmount to a specific interface by using the RC_NEED="net.eth1" in conf.d/nfsmount. I infact have been using RC_NEED="openvpn" for my nfsmount as it only works across openvpn. Hopefully this addresses everyones concerns. Thanks -- Roy Marples <[EMAIL PROTECTED]> Gentoo/Linux Developer (baselayout, networking) -- [email protected] mailing list
