Re: Don't disable recoomends by default

[Urs Thuermann <urs@isnogud.escape.de>]

Jonas Smedegaard <jonas@jones.dk> writes:

> Quoting Stephan Seitz (2019-07-12 09:30:38)
> > On Fr, Jul 12, 2019 at 09:13:29 -0300, Jonas Smedegaard wrote:
> > >Wrong.  Suggests are for packages useful only "sometimes", recommends
> > >are for pacakges needed in "all but unusual installations."
> > 
> > From my experience this is wrong.
> > 
> > With recommends my d10 update would have systemd as init instead of 
> > sysvinit. And I would have got (for example) the package debsecan 
> > which I donâ??t need.
> > 
> > So it is better to disable recommends and look at the recommended 
> > packages.
> 
> There is nothing wrong in suppressing specific recommendations where you 
> understand the implications.
> 
> 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.

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?

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.

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.

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.

Sometimes a package foo recommends foo-doc while others only suggest
foo-doc.

I could easily extend this list with a dozen more examples.
Installing all recommended packages would increase my installation by
a couple 100 MB, maybe GB.  And this is not only wasted disk
space but also increases the probability of security bugs, which is
bad if the specific packages is actually unused.

But even more annoying is that some packages specify Depends: on other
packages where this should not be the case, IMHO.  This is why I have
cups, bluetooth libs, bluray libs, IEEE1394 libs, MIDI libs, braille
display libs, libs for Wacom tablets, and several dozens of unused
packages on my server machine which has no audio, no bluetooth, no DVD
or Bluray drive, no braille terminal, no printer, no firewire, no
graphical display, ... nothing except a 80x25 text console, lots of
disks, and an Ethernet port.

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.

urs