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/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature