Bug#688772: gnome Depends network-manager-gnome
]] Steve Langasek
> And by the way, if you're going to treat it as a serious bug, you'd better
> get filing other bugs for consistency. Just off the top of my head,
> base-passwd has had the same handling of /etc/passwd for *years* without
> anyone objecting. To me, this is very clearly a matter of moving the goal
> posts.
I file those bugs whenever I see them and has been doing this for a
while. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558784 for
another example.
> > It's not ok to replace a config file just because it has a syntax error in
> > it, is it? Also, see below.
>
> Replace, no. Repair, maybe.
I don't think it should do that, it should notify the admin. Trying to
guess the intentions of admins is not particularly easy.
> > > 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 don't see where the previous TC ruling says that ifupdown is special.
> Rather, it says that upgrading gnome-core shouldn't cause network-manager to
> clobber the user's network preferences on upgrade, /whichever/ tool they
> were using to manage those.
I did explicitly say it was a natural consequence of the ruling, not
that the ruling itself said so. The alternative is for the relation to
be symmetrical, so ifupdown should stay away from managing interfaces
where there exists a NM config for the interface without there existing
an explicit configuration for the ifupdown interface? It's easy enough
to generate such a configuration by using mappings, for instance.
This becomes a nightmare once you drag wicd into this and all tools need
to know about what other tools might want to manage an interface. I
think it's important that we end up with something that's actually
supportable, rather than something which might be formally better, but
in practice so complex it becomes brittle beyond repair.
> That should be trivially easy in the case of lo. If the /e/n/i entry for lo
> is missing, or matches this:
>
> iface lo inet loopback
>
> ... it's fair game. If it's something else, then /against all reason/, the
> user has configured lo in a non-standard way, and NM should respect that.
>
> So I don't think this bug in ifupdown in any way blocks NM from being able
> to do the right thing. If you disagree, let's explore this further.
I don't think I've said it blocks NM from doing the right thing. I've
said it's a bug in ifupdown.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: