I am posting this on -devel because I think that it rather belongs here than in the context of #681834 and the discussion in -ctte
On Sat, Oct 06, 2012 at 09:41 +0200, Josselin Mouette wrote:
> Le vendredi 05 octobre 2012 à 22:07 -0600, Bdale Garbee a écrit :
> > I personally believe that metapackages should be primarily populated
> > with Recommends, with Depends largely reserved for actual technical
> > dependencies between real packages.
I would like to point you to the last time this suggestion was discussed in
debian-devel [0] as it contains a number of arguments that might otherwise go
unnoticed.
Unfortunately this issue/thread is an amalgamation of a number of
independent issues and it might make sense to discuss them independently. I
can easily make out the following:
1. Is the action to change the network manager dependency in the gnome
metapackage in the spirit of the CTTE resolution?
2. What is the relation between GNOME and network manager (NM). How
tightly do they *need* to be coupled and what are the
technical/usability implications of using GNOME without it.
3. Interoperability of NM with other network configuration
mechanisms/tools such as /etc/network/interfaces, wicd, manual
configuration, ... and in particular bugs therein. (i.e. What happens
if NM gets installed even though the administrator configured the
network in a different way)
4. How should metapackages be implemented and how should they be treated
by apt?
5. How should the Desktop task be installed during the initial
installation and how can users tweak that?
There are probably more, but these pop into my head right now. I do not want
to comment on (1) but it might make sense to discuss the others first as that
might very well make a CTTE resolution redundant. I also can not gauge (2) and
would be happy if members of the Gnome team could comment on that, but (3)
should clearly be discussed within the scope of applicable bug reports that
can then be fixed.
As you might have guessed it is mostly (4) and (5) that are most important to
me and it would IMHO be beneficial to discuss this in a broader scope (maybe
in debian-policy) and codify the decision in the policy.
1. Motivation for a change - What is the problem?
=================================================
The main motivation for a change to the current implementation was given in
[0], the DEP-6 discussion [1] and by Bdale:
>> This is consistent with my belief that we should try to empower our users
>> to be able to exercise a reasonable amount of choice in configuring and
>> operating their Debian systems.
A common argument formulated by the GNOME team (or members thereof) is:
> Maybe you are unfamiliar with what clueless newbies do with their
> systems. You want to empower users, that’s fine; but GNOME is for all
> users. Those who have the technical knowledge to handle their packages
> manually should also know how to make it happen without metapackages.
which is certainly true, but doesn't capture one *very* important aspect. Sure
"clueless users" won't really care and are happy to get a GNOME installation
that packs everything and the kitchen sink. This is good IMHO and encourages
exploration of different software options in a unified and well integrated
environment. It is also true that "advanced users"/"power users"/Debian
Members/Unix beards/… can easily finetune their installation or even create
new personal metapackages, but …
The problematic use case are users who are proficient enough with Debian to
realise that they do not want a set of packages and who try to remove them,
but who do not (yet) know enough about Debian and its actual implementation to
do so. The current implementation makes it incredibly hard (see [2] for
"solutions")
to finetune a "kitchen sink" systemi). I think that the wish to explore and
finetune a system is typical for new users who get familiar with their system
and they should be encouraged and supported in doing so.
2. What can be done?
====================
Two proposals are commonly made to rectify the situation:
1. Use Recommends in metapackages
2. Treat metapackages differently during removal/purge
After thinking about this I am still convinced that (2.1) is the better
solution as it allows users to remove some packages that were pulled in by a
matapackage without causing its complete removal. I dislike (2.2) because it
means that "apt-get install METAPKG ; apt-get purge METAPKG" does not (in terms
of
installed packages) change anything. It would essentially mean that there is
no inverse element/action for "install".
Arguments against (2.1) comprise:
* Recommends is wrong for metapackages because it gets upgrades very
wrong. This is why it is used very marginally. [3]
Not sure about this and Josselin unfortunately did not elaborate on
actual problems.
* […] there is the problem that versioned Recommends are useless, while
we often want to guarantee that an optimal version combination is
installed. Worse: they are ignored […] [4]
* […] there’s the problem of keeping testing usable. You don’t want a
metapackage to migrate until all the packages it brings have also
migrated, otherwise testing systems could become unexpectedly unusable.
[4]
* Policy 7.2 [5]
This is IMHO a problematic argument as there really is no technical
reason for a hard dependency in the context of a metapackage which is,
in nature, the implementation of an abstract idea. (e.g. GNOME *is* this:
…)
There are certainly others, but those are commonly mentioned.
One aspect that is incredibly important in the light of this discussion is
that (2.2) *has already been implemented* AFAICT. Ever since #574851 we do
have a metapackage section and apt currently ships
/etc/apt/apt.conf.d/01autoremove with the following in there:
--- snip ---
APT
{
[…]
Never-MarkAuto-Sections
{
"metapackages";
[…]
};
};
--- snip ---
which means that metapackages are not automatically removed right now. (IIRC)
The problem is that "gnome" et al. do *not* belong to the "metapackage"
section but to "gnome" so they are not treated as such. (use [5] to list all
25 packages in that section)
It seems as if the metapackage section is not widely used and I think that the
current situation will just cause unpleasant surprises in the sense that some
metapackages are removed while others are not. I also don't feel good about
the fact that the current behaviour is not really documented or codified in
the policy.
In summary I would say that we should discuss metapackages and their usage and
how they are installed/presented to the user during the installation in a
broader context. It might, for example, be the best way to offer a wider range
of options than just "Desktop" during the installation.
[0] http://lists.debian.org/debian-devel/2011/08/msg00693.html
[1] http://dep.debian.net/deps/dep6/
http://lists.debian.org/debian-devel/2009/12/msg00550.html
[2] http://lists.debian.org/debian-devel/2011/08/msg00729.html
[3] http://lists.debian.org/debian-devel/2012/07/msg00210.html
[4] http://lists.debian.org/debian-devel/2011/09/msg00001.html
[5] List of packages in the metapackage section: $ aptitude search
'?section(metapackages)'
--
Wolodja <deb...@babilen5.org>
4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
signature.asc
Description: Digital signature
