On Fri, Dec 14, 2012 at 09:50:37AM +0100, Tollef Fog Heen wrote: > ]] Steve Langasek
> > - Installing the gnome or the NM package must not cause the network to > > break on upgrade, even temporarily, under any circumstances. > Is this a requirement for other network-providing packages as well? If > so, openvpn for instance is RC-buggy because upgrading it will restart > any configured VPNs. We don't require other packages to continue to > work uninterrupted during upgrades, and while I can agree NM is in a bit > of special situation by virtue of controlling the network, I am not sure > being as strict as you are here is reasonable. Sorry, my wording was a bit sloppy there. What I meant to say was, "an upgrade that pulls in either gnome or network-manager as a new package must not cause the network to break, even temporarily". So on new installation of the NM package, my expectation is that it will not tamper with the current network state, because doing so may break the admin's remote connection to the machine. I think it's important that an upgrade of the NM package *also* not cause the network to drop, but that's a slightly different point than the one I was meaning to make. > > - Installing the gnome or the NM package must not cause any network > > configuration the user has specified to be lost. > This is reasonable, and makes ifupdown RC-buggy, since rm-ing > /etc/network/interfaces and reinstalling the package will change the > network configuration (the file is recreated). I've just filed a bug > about this. I think you're missing several steps in your proof that this is RC buggy. ;) The policy requirement isn't that *filesystem* changes be preserved, it's that *configuration* changes be preserved. In what way does deleting /etc/network/interfaces constitute a valid configuration that must be preserved? When ifupdown recreates the file, it populates it only with a config for lo. I don't think it's reasonable to claim that it's valid and intentional to configure a system in such a way that it will fail to bring up the loopback interface on boot. In fact, booting the system without lo breaks so many assumptions that Ubuntu, for example, *unconditionally* brings up lo on boot, whether or not it's configured in /etc/network/interfaces. I consider restoring a stock /e/n/i on package upgrade to be in the same category. If the reason you raise this concern is because of my comment that NM should always report the system "online" unless it controls all the network interfaces, I was implicitly excluding lo from the reckoning. First, it's not relevant to whether the machine is online, and second, there's only one valid state for this interface ("up") so there's no configuration to fight over the management of. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature