On Thu, 17 May 2007 19:53:07 +0200 (CEST) "Thijs Kinkhorst" <[EMAIL PROTECTED]> 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/
pgp1PLHqXPiDI.pgp
Description: PGP signature