On Thu, 17 May 2007 11:29:16 +0200 Hendrik Sattler <debian@hendrik-sattler.de> wrote: > Hi, > > what I am really missing in the current dependency scheme is WHY some packages > define Recommends and Suggests on specific other packages. I use Recommends or Suggests when the package includes a variety of scripts with broadly related purposes. The main Depends: line is determined by a "core" set of scripts (which may be described in detail in the long description) but if there are a couple of optional scripts that some people may like to use but which aren't strictly essential to the use of the package, then those dependencies get put into Recommends or Suggests. The meaning, to me, is: Recommends: needed or useful in conjunction with optional or limited usage scenarios where alternative methods may exist. Suggests: Not a strict dependency of any script in the package, just useful for helping the user find their way around the package. e.g. dwww for docs. > My problem with the current situation that you either do the policy of always > installing such stuff or you don't. There is no way to decide case by case > because there is definitely information missing in the description of > packages. You install a Recommends or Suggests when you want to use some part of the package that uses it. The obvious place to document such requirements is the manpage for the optional script. In most cases, users simply don't need to use those options. e.g. emdebian-tools Recommends subversion because although the "core" emdebian-tools scripts can be used without subversion, there is an optional script which requires subversion. Not everyone using emdebian-tools needs to use the optional script (emsource) because emsource is a cross-build-aware wrapper for 'apt-get source' that also manages the Emdebian SVN. If you aren't using the Emdebian SVN, emsource is of little use to you. Making subversion a dependency of emdebian-tools would be pointless. Having said that, emsource is becoming more like a core script and a later release may deprecate using apt-get source directly and migrate emsource into the "core". > OK, some of those are obvious but some Recommends and Suggests are completely > mysterious to me. Until you use the package and come up against the one area where the Recommended package is actually useful, this is to be expected. Until you need to use that one option, there is no need for you to be concerned. At the point where you need that option, the manpage for that script or program should explain the role of the recommended package. > And even after installation, I still don't know how those > additional packages do extend/improve/whatever the originally wanted package. That isn't a problem - when you want to use a particular feature, the manpage should provide the info you need. > It would be nice if maintainers of packages with Recommends and Suggests that > are non-obvious could state in the package description a reason for each of > them. Package descriptions can be long enough as it is - IMHO the best place for this information is the manpage. Things like "Recommends" often needs context - the reason for using the recommended package needs to be explained in relation to the rest of the scripts and the overall purpose of the package. There is no room to do that in the description. > If I file bugs about them, which severity can this be given? wontfix. ;-) The location of this information should be the manpage, IMHO. Moreover, it should be the manpage of the specific program/script that uses or is related to the recommended package. The only bug suitable for this scenario is a wishlist bug for a more verbose manpage. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpZM09k0hxuJ.pgp
Description: PGP signature