Bug#688772: gnome Depends network-manager-gnome
]] Steve Langasek
> 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.
Ok, fair enough.
> 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.
My question then still stands: Do you consider NM in any way special
here or does the same requirement apply to other network-providing apps?
> > > - 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. ;)
I had enough steps in there that one of the release managers agreed with
me.
> 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?
The policy requirement is not that the configuration changes are
valid. It's not ok to replace a config file just because it has a syntax
error in it, is it? Also, see below.
> 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.
Putting «iface lo» into /etc/network/interfaces is not only a way to
ensure there is a loopback interface on boot. It's also a way for
ifupdown to claim to handle that interface (this is a natural
consequence of the CTTE ruling; that ifupdown is special and has
precedence and other tools should stay away from interfaces where there
is a ifupdown configuration for the interface), so if ifupdown does add
that configuration, there is no way for me to have ifupdown installed so
I can read the man page at the same time as letting other tools manage
lo.
I might also dislike the name «lo» for loopback and rename the lo
interface to something else, and let «lo» be the name of yet another
interface. It's a bit crazy, but not much cares about network interface
names apart from the network configuration tools, so this would actually
break a most unusual, but otherwise valid configuration of the network
stack. ifupdown would break that configuration.
> 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.
Your mail triggered me to go look, but it wasn't otherwise directly
related, no.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: