[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> 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

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: