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

Bug#681783: Are Recommends really important (especially for metapackages)?

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 

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.

[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 
[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,
Offtopic discussions among Debian users and developers:

Attachment: signature.asc
Description: Digital signature

Reply to: