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

Re: Reasons for recommends and suggests



On Thu, 17 May 2007 19:53:07 +0200 (CEST)
"Thijs Kinkhorst" <thijs@debian.org> wrote:

> On Thu, May 17, 2007 11:58, Kevin Mark wrote:
> > Package: mutt
> > Suggests: ispell [adds spell cheking while composing emails]
> > Suggests: urlview [extracts urls from email and can lanuch a web browser]
> > Suggests: mixmaster [allows you to compose anonymized email]
>
> This seems like a useful idea to me. As a technical detail, I'd use '('
> and ')' because those are used for optional comments in the RFC822 format
> already.

() are used for dependencies in other control fields - I would see '('
as a recipe for confusion.

> On Thu, May 17, 2007 19:22, Neil Williams wrote:
> > The only bug suitable for this scenario is a wishlist bug for a more
> > verbose manpage.
>
> It seems cumbersome to me to be presented with a list of recommends and
> suggests at install time, ignore that and finish install, read the manpage
> and then go back to the package manager to install extra packages. I'd
> rather just make that decision when I'm at the root prompt anyway.

? sudo ?

Most users don't need to use the packages given as Recommends or
Suggests so the purpose, as I see it, is to help those who have unusual
or extended needs for the functions provided by the package. Are you
likely to know whether this is appropriate until you've had a chance to
use the package?

BTW: read which manpage? My example is from a package that is a
toolset. Out of the collection, only one script needs subversion right
now. There are multiple manpages in the package - only one describes
the role of subversion. Understanding whether you need that
functionality requires context - you cannot necessarily decide upon a
crude one-liner.

Take another package of mine: pilot-qof.

Recommends: libqof-backend-sqlite0, datafreedom-qsfxsl, datafreedom-perl
Suggests: datafreedom-doc

To me, the purpose of these two lines is simple: highlight that these
packages are related to pilot-qof in some way. If the user wants to
find out more, man pilot-qof is the only sensible option because the
purpose of each recommendation or suggestion needs to be explained
within the context of what the package itself can actually achieve.

Over-simplification doesn't do anyone any favours - it can promote
something that the package cannot do or it can omit something that the
package can do. Some things just need to be explained in detail,
within the overall context of the relevant packages. That is one of the
purposes of a manpage, IMHO. To let the user find out "How do I use X?"

In turn: datafreedom-qsfxsl:
Recommends: pilot-qof, gpe-expenses, zenity, datafreedom-doc
Suggests: calcurse, dlume, dates, contacts, gpe-contacts, gpe-calendar

These are some of the applications that can import or convert data
converted by the XSL within the package or are used by scripts based on
the XSL in some way.

Full details of what fits where and when one package is recommended
over another from the same list cannot be contained within an
over-simplified one-liner. These details are in the manpage(s) and
further documented in the suggested -doc package.

It's my way of saying that if you use any of the suggested packages,
some of the recommended packages can be used to share data with the
applications that you actually use. None are essential, I doubt that
anyone, except me, has all of the recommended and suggested packages
installed. You cannot sensibly make the choice until you've tried out
the package and decided which other package and which scripts best fit
your needs.

This problem is common to all kinds of toolset, conversion,
inter-operability and data synchronisation packages.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpa_YnxhwwiA.pgp
Description: PGP signature


Reply to: