On Lu, 05 aug 19, 22:50:17, Urs Thuermann wrote: > Jonas Smedegaard <jonas@jones.dk> writes: > > > > What is wrong is to suppress all recommendations by default. > > I have done this for years now, i.e. I have > > APT::Install-Recommends "false"; > > in /etc/apt/apt.conf and I haven't had any problems, unexpected > behavior or non-functional software packages. > > OTOH, IMHO many packages have recommendations I don't like, especially > if "Recommends:" means it is recommended except in unusual > installations. > > For example a number of packages (e.g. geeqie) recommend cups or lpr > although it's not that unusual to not have a printer. True. It would also provide a very bad experience for those that do have a printer, but can't guess they need to install this peculiar package named "cups" to make it work. As more printers are now available via the network (good) it's not even easy to autodetect the printer in the installer. For the archives, pinning cups to -1 would nicely deal with this for those that really don't want cups installed. > For some reason I don't know, nfs-common recommends python. I have > used NFS for >25 years now, most of the time without Python and > without any problems. And why does it recommend python (i.e. 2.7) > instead of python3? Sounds like a bug, please report. > Why does nut-client recommend bash-completion? It's not that unusual > that admins work with ksh or zsh or some other shell only and > therefore don't need bash support. This should probably be a Suggests, even if bash is the default shell. > And auctex recommends a list of PDF viewers (or okular which can show > DVI files) while I know still many users who work with xdvi only. So > using auctex to write TeX files should not imply the user also wants > PDF or okular. PDF has become the de facto standard for sharing (not easily editable) documents. Most of the people I know (outside Debian/FLOSS) wouldn't even know what a dvi is. Not generating PDFs is a rather unusual case. The Recommends could probably be improved to use the pdf-viewer virtual package instead (unless the package maintainer has good reasons not to). > Some packages recommend specific mail readers (e.g. logrotate or > smartmontools) when they only need a MTA to send the mail. Where the > mail is forwarded to and which MUA the admin uses to read it should be > out of the scope of those packages. The package 'at' does it right by > only recommending mail-transport-agent. Reading the above one could think they recommend mutt, etc. when they in fact recommend mailx. If you worry about its installed size it really is an unusual system. Besides, their mail sending code might not know how to deal with an MTA directly. > Sometimes a package foo recommends foo-doc while others only suggest > foo-doc. The Recommends would make sense on a package with a TUI/GUI able to display that documentation from a Help menu. Should probably be demoted to Suggests for most other cases. > I would like if many of these packages wouldn't link against these > libraries (and therefore depend on it) but would instead only call > dlopen(3) when the functionality in question is actually used (and > recommend or suggest those libs), and give a diagnostic message if the > lib is missing. Debian's default is to enable most (if not all) options on packages, which makes sense for a binary distribution. If you require that level of selection Gentoo or Arch might be better suited for you. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
Attachment:
signature.asc
Description: PGP signature