> Russ Allbery writes ("Bug#688772: gnome Depends network-manager-gnome"):
>> I've been thinking about this over lunch, and I do feel like the gnome
>> metapackage is substantively different than the gnome-core metapackage.
>> I'm not sure if it's sufficiently different to warrant a different
>> decision, but it does seem different enough to warrant a separate
>> discussion.
One of the major complaints was, that there is no longer a meta-package
which gives a sufficient and complete enough GNOME desktop environment
without a NM dependency. The gnome-session package was considered to be
not appropriate.
Joss solution definitely addresses that while trying to preserve our
vision what we (as a team) and upstream define a default GNOME environment.
Assuming bad faith and the language that was chosen by Ian really
troubles me, especially his attempt to reprimand Joss.
Somehow I have the feeling Ian is taken this whole issue to personally
(which he admits himself) and that clouds his judgements on a technical
level.
That all said, and I hope we can leave this behind us, as this "infight"
leads nowhere.
> Most of the points that were determinative of our decision on
> gnome-core apply to gnome too.
>
>> The historic point of the gnome metapackage is not to just install the
>> base machinery of GNOME in the same way that gnome-core is. It's rather
>> to give the user a complete desktop environment built around GNOME. There
>> have historically been all sorts of applications in there that people may
>> or may not use. It's a fairly "heavy-weight" metapackage; it pulls in
>> everything from office suites to a mail client.
>
> All of that is fine but of course as you yourself wrote:
>
> 4. For most applications and components, the only drawback of this would
> be some additional disk space usage, since the application, despite
> being installed, wouldn't need to be used. However, network-manager
> assumes that, if it is installed, it should attempt to manage the
> system's network configuration. It attempts to avoid overriding local
> manual configuration, but it isn't able to detect all cases where the
> user is using some other component or system to manage networking.
> The user has to take separate, explicit (and somewhat unusual for the
> average user) action to disable network-manager after it has been
> installed.
>
> So n-m is special.
Actually, NM is not really special. The "gnome" and "gnome-core"
meta-packages install a wide variety of applications and infrastructure,
which are
a/ active by default. E.g. components like avahi-daemon are started by
default.
b/ being used as default application after being installed, e.g. via
mime associations and default settings. The GNOME desktop environment
sets up a default web browser, email client, Texteditor, Music Player
etc. Whenever you try to open a file, a link, those default applications
will be opened. The user needs to explicitely configure other
alternatives. This can mean changing dconf/gconf settings, and requires,
as Ian called it, "unusual, explicit actions".
So it is false to say that those applications only use some disk space
and aren't noticeable when not used.
Indeed, I would argue that for most users, the default choice we set for
the web browser, email client, video or music player, etc. is a much
more visible and important issue.
> But the upgrade issue is the same and will affect nearly as many
> users. And on the face of it it is simply entirely wrong to upgrade
> the dependency. I can see no justification for it. And the
> maintainers haven't even provided one!
This is simply wrong. The GNOME team (and others) has provided a
justification on several occasions. It's simply that Ian conveniently
dismisses/ignores that.
The reason the Recommends was upgraded to a Depends is twofold:
a/ a much tighter integration of NM into the desktop compared to
squeeze.
This involves integration into the Shell, gnome-control-center,
applications making more extended usage of NM, e.g. PackageKit being
more clever and trying to avoid costly updates when being online via
Mobile Broadband. Just to name a few examples.
b/ a change in how our users have become more mobile.
Wireless is a commodity nowadays, Mobile broadband for many is an
essential feature they use on a daily basis. Or the road warrior which
needs VPN access. Only NM provides these features today.
> What you are proposing is a compromise between doing the right thing
> for our users, and upholding the autonomy of the maintainer.
Changing the Depends to Recommends was never the right solution to the
real issue, imo. The underlying problem is that:
a/ some users will always be unhappy with the choices we make for those
meta-packages. Some want A instead of B, some want no C at all, some
want D being added and such. It is simply impossible to please everyone.
My simple recommendation for such users is, to juse not use those
meta-packages then and pick and chose what you want instead.
You do that *once* during a dist-upgrade and you can take the
meta-package we provide as input. So this isn't a lot effort.
I actually somehow doubt, that there are a lot of squeeze users, which
have the whole gnome meta-package installed but decided to remove NM.
So this upgrade scenario which was mentioned as one the main points
isn't a major issue in practice.
b/ among those users are some that are unhappy with NM. That doesn't
need to be based on actual, technical issues. Some just don't like it.
As for users which have real problems with NM, this is something we can
fix, if we know about those problems. So far, I don't remember those
users providing more details, so I can only tell what I know about:
1/ NM's handling of /e/n/i when being installed, where it comments out
plain DHCP interface configurations so it can manage that interface.
Some users don't like that automatic mangling.
2/ NM's handling of /etc/resolv.conf. When you have both ifupdown and
NM manage a (different) device, it can happen that NM overwrites or
clears /etc/resolv.conf.
Both those issues are currently being addressed.
for 1/ we have patches pending for d-i, so we no longer need that
/e/n/i mangling in NM or at least can make it optional being hidden
behind a debconf prompt.
for 2/ I plan to change how NM manges /etc/resolv.conf in the presence
unmanaged devices and be more conservative.
If there are other issues, then I urge anybody to report them. I/We
can't fix issues which we don't know about.
I would really appreciate, if the ctte could leave this case as it is
now and let us concentrate our efforts on fixing real issues and bugs
instead of having to spend our time writing several pages long emails
where we need to defend our work. The lack of trust that was shown
towards us has definitely saddened me and taken out all the fun and
enthusiasm I have for Debian.
Let's not work against each other.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature