Package: tech-ctte
Dear Technical Committee,
Following the big sub-thread "Recommends for metapackages" on
debian-devel[1] I would like to submit following questions to you as per
Debian Constitution 6.1, item 5 ("Offer advice"). Examples below are not
meant to request specific decision(s) from your side or even to point
fingers at any one package Maintainer (DD or not), but to better explain
what I think is a more general problem that you could address.
= Timing =
I am aware of the freeze for Debian 7.0 (a.k.a. wheezy) and do
understand that a possibly favorable outcome is too late to have any
significant impact on its release (except for possibly delaying it with
lengthy discussions). However, since it is my hope that such a
potentially favorable outcome inspires at least some changes for the
next release, it should not occur much later than shortly after the
release (e.g. when or right before the Release Team is asking for
release goals).
= Context / Rationale =
I have been watching Debian development since before APT defaults have
changed to install Recommends by default. As an aptitude user one of the
first settings to do at the time for any new installation was to disable
Recommends, in order to get decent installation sizes.
As soon as the default for APT was changed I did so myself on my
unstable machine and started filing bugs to suggest adjusting
dependencies according to the new Debian-wide default. In most cases
Maintainers have been very responsive and IMO, due to their efforts,
today it is possible to have a decently sized installation even with
Recommends enabled.
However, in past years I have witnessed a few cases where maintainers
insisted on using a Depends relationship, even though many others
(including Debian Developers) had strong arguments to the opposite[2].
This and the "Recommends for metapackages" sub-thread seems to indicate
that opinions are still quite divergent regarding Recommends.
Given the above and also the recent problems in fitting the two major
Desktop Environments on only one CD each it would probably help if the
Technical Committee would take some official position on the following:
1. Is running a system with Recommends turned off a supported
configuration?
It seems quite a few Debian Developers consider this rather a supported,
normal configuration, and not a customized, special purpose one.
Apparently, as a consequence, there is a tendency of having stronger
than necessary package relationships.
IMO this hurts the very people who would benefit the most from disabling
Recommends: the ones who actually trim down an installation to the
minimum, since overriding a Depends is so much more difficult (assuming
one does even find out about the exaggerated ones).
Based on this rationale, packages should not use Depends unless the
given package as provided by Debian is unusable (e.g. it would crash)
without the depended package. An obvious example would be an application
and it's libraries.
Another, maybe not so obvious consequence is that Maintainers tend to
use Recommends where Suggests would be more appropriate, leading to
bloat also in default installations. IMO packages should not use
Recommends unless it really makes sense to have both packages installed
in most cases.
Expanding on the previous example, a library should probably not
Recommend an application, but rather use Suggests. In most cases users
will not be installing libraries directly anyway and if the library
gains new reverse dependencies suddenly unrelated packages are installed
on users' systems[3][4].
Circular Recommends (or Depends/Recommends) relationships should also be
avoided if technically feasible, as this renders the autoremoval feature
of package managers almost useless.
If you agree that by disabling Recommends the system administrator
assumes responsibility for the lack of possibly important
functionality that may even lead to breakage (e.g. rsyslog only
Recommends: logrotate), this may need a coordinated effort to
write/adjust some documentation (manpages of package managers, Debian
Reference, Developer's Reference, Release Notes and possibly others). I
am willing to help in this regard as much as time allows during the
following release cycle.
2. Are Depends appropriate for metapackages?
In the above mentioned thread it has been argued that the purpose of
metapackages is to _guarantee_ a certain set of packages is installed,
while others argue that Recommends is more than sufficient, given that
they are installed by default, and it also makes removing individual
components much easier.
Potential problems on upgrades have been mentioned when using only
Recommends, but as far as I recall the only concrete example was package
managers not installing _new_ Recommends by default, which at least for
apt is not true (according to one of its Maintainers) and should be
fixable for any others in time for the wheezy+1 release.
IMO metapackages should be using Depends only in very special cases
(e.g. a Destop Environment doesn't make much sense without the
corresponding session manager)[5]. If other packages in the collection
strictly require a specific package they would already depend on it
anyway and system administrators should be given an easy possibility to
remove individual components from a collection.
I think this is related to 1., and it would probably make sense to take
a formal position on this matter too.
References:
[1] http://lists.debian.org/20120710135212.GA5107@r500-debian
[2] #515214 - X can run perfectly well (or even better) without HAL.
Please make this a Recommends: at most
[3] e.g nmap now uses the system liblinear, which at the time of this
writing pulls in gnuplot, groff and psutils (via liblinear-tools and
libsvm-tools, most of them through Recommends). #679992 was filed just a
few days later after I wrote an e-mail to the Maintainer.
[4] maybe a lintian check like lib-recommends-non-lib-package would make
sense?
[5] assuming a reliable method to detect metapackages maybe a lintian
check like metapackage-depends-on-non-metapackage would make sense?
Thank you for reading,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
Attachment:
signature.asc
Description: Digital signature