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

Re: Reasons for recommends and suggests

On Fri, May 18, 2007 at 02:04:15PM -0400, Joey Hess wrote:
> Kevin Mark wrote:
<my desktop user reasoning>> 
> A desktop user is perhaps not the best example, since recommends might
> as well be depends to such a user -- they're both things that aptitude
> installs when the software is selected. Such a user is also better
> served by using the desktop task (which will install evolution-exchange
> for them BTW).
> Tasksel has the problem that it's still not safe to turn on installation
> of all recommends of packages in tasks, because recommends is aparently
> overused a lot. Without recommends, tasksel installs a pretty nice
> desktop environment; if recommends is turned on, 17% more disk space is
> used by the recommended stuff. (#388290) Perhaps a few of those packages
> would be useful additions to the regular desktop install, but I have not
> yet had the fortitude to go through the list, work out what, and file
> bugs on the rest.
> Cleaning up the recommends to meet policy seems far more useful than
> documenting a bunch of bogus recommends, although the idea of putting
> small comments in dependency fields is something I'd much like to see
> anyway, especially if it were extended to all fields (including
> Build-Dependencies[1]). Comments, after all, can be a very useful thing
> from time to time.
So here is what I take-away from your post:
From the desktop user perspective, they will not know much about what to
select and thus will install the 'desktop' task. They will also not
change the default behavior of aptitude which install 'recommends'. This
[at least according tothe definition] will install usefull things that
most average users of said package will need. Thus they will run the
various pieces of software and should 'just have' most of the expected
functionality available. So, knowing what each 'recommends' adds in
functionality is not needed. And, at the point extra functionality is
needed, the user will have to investigate the available resources,
post-initial-install, like READMEs, man pages, etc. to determine what
should be installed. 

While that seems reasonable, I think adding the comment would be great
so that folks could be explicitly told why a 'recommends' is being added,
knowing full-well that its not a replaccement for reading more lengthy
and through documentation because the maintainer knows when they add a
'recommends', it adds something specific and I think that thought should
be conveyed to the future users of the package. And I guess to shorten
the comment, the language for the comment should include domain-specific
terminology and jargon. 

You also advocate at the same time for adding a syntax for comments to
various (packaging?) fields, which is, as you say, generally userful. No
argument here.So at some point in the future there will be
infrastructure for said 'recommends' comments. If that does come to
pass, then the functionality can be added to aptitude to read and
display said comments. Hmm. Same result from a different perspetive.

Now as for the need for re-classification of 'recommends' to say
'suggests' to trim (mega|giga)bytes from the basic install sounds like a neat
idea and a way to help with that is to have the maintainer have a simple
file that explains the association between the package and its
recommends(kind of like the proposed comments) so that it can be peer
reviewed if someone questions its usefulness in a regular install with

debian.recommends.txt for mutt
mutt-print: adds a way to print mail using tex formatting
gnupg: used to sign and/or encrypt incomming/outgoing mail
|  .''`.  == Debian GNU/Linux == |       my web site:           |
| : :' :      The  Universal     |mysite.verizon.net/kevin.mark/|
| `. `'      Operating System    | go to counter.li.org and     |
|   `-    http://www.debian.org/ |    be counted! #238656       |
|  my keyserver: subkeys.pgp.net |     my NPO: cfsg.org         |
|join the new debian-community.org to help Debian!              |
|_______  Unless I ask to be CCd, assume I am subscribed _______|

Attachment: pgpLQDbgIl4GW.pgp
Description: PGP signature

Reply to: