Re: Opt out style recommends
Adrien CLERC wrote:
> Le 08/04/2016 05:49, Harlan Lieberman-Berg a écrit :
> > [1]: I say default here, but really, systems which turn off installing
> > things which are Recommended are almost unusuable; I know for a while
> > it was the policy of #debian to just turn away people who had done
> > that because the system would be in such a strange state.
> While I think installing recommended packages by default is a good
> choice, disabling it is also a really good option on servers. Installing
> every recommended packages is sometimes the best way to bloat your system.
Agreed. I turned off Recommends years ago on all my systems, because it
installs too many things I don't want (by both the mild "takes up
space" criteria and in many cases the "don't want an extra daemon
running" criteria).
Here's a Python script (using python-apt, which you'll need installed)
that will find and print all unsatisfied Recommends on your system:
#!/usr/bin/python
import apt
c = apt.Cache()
for pkg in c:
if pkg.installed is not None:
for rd in pkg.candidate.get_dependencies("Recommends"):
if not rd.installed_target_versions:
print pkg, rd
I'm not going to go through a full analysis here, but here's a *tiny*
subset of the output on my system, with some annotations:
aptitude Recommends: aptitude-doc-en | aptitude-doc
Why would all but the most unusual configurations need an HTML version
of the manual installed? aptitude already ships a text version in
/usr/share/doc/aptitude/README, and includes a menu option inside
aptitude to display that. The HTML version is also available online.
So only people who 1) want the HTML manual and 2) want it available
offline need one of these packages installed.
https://bugs.debian.org/820452
autogen Recommends: autogen-doc
I only have autogen installed as a build-dependency of grub. Also,
autogen already includes its documentation in info format; autogen-doc
just provides precompiled PostScript and HTML.
I wonder if debian-policy section 12 should talk about the desired
package relationship between <package> and <package>-doc? For instance,
"If <package> is a build tool, command-line tool, or library, <package>
already provides documentation in man, info, or text format, and
<package>-doc provides HTML or other formats, <package> should have a
'Suggests: <package>-doc'. Otherwise, <package> should have a
'Recommends: <package>-doc'."
brasero Recommends: brasero-cdrkit
This one makes a bit of sense, since GUI tools should try to have all
their functionality work automatically. (Odd that brasero-cdrkit itself
only Depends on the tools needed for audio CDs but Recommends the tools
for DVD authoring.) On the other hand, since the gnome metapackage
pulls in brasero, this directly adds a pile of packages to standard
desktop installs.
cron Recommends: exim4 | postfix | mail-transport-agent
Subject of a great deal of debate. I've worked on patches to make cron
capable of logging output rather than send email. I'm hopeful that
someday a default Debian install (of either standard or a full desktop)
will not include a running MTA, even with the default configuration that
has Recommends enabled. But for now, I'm glad that at least nothing I
have installed has a hard Depends on an MTA.
cups Recommends: printer-driver-gutenprint
Why does cups recommend some printer drivers and only suggest others?
For instance, I have printer-driver-hpcups installed instead.
devscripts Recommends: at
Don't want an extra daemon running, and I don't use the only tool that
wants this.
dict Recommends: gawk
Not actually used by the "dict" tool, but by a separate tool "colorit"
that dict ships, unrelated except that they come from the same upstream
source package. Perhaps dict could split out colorit into a separate
binary package? https://bugs.debian.org/573608
emacs24-common Recommends: emacs24-el
I don't think all but the most unusual configurations need the elisp
source of the functionality already provided by the main emacs24
package. Emacs/elisp developers will want this.
empathy Recommends: telepathy-haze
I only have empathy installed because GNOME depends on it.
evolution Recommends: bogofilter | spamassassin
I only have evolution itself installed because GNOME depends on it; I
certainly don't need additional dependencies for its optional
spam-filtering plugins.
gdb Recommends: gdbserver
Doesn't actually seem likely that most users of gdb will use gdbserver
on the system they install gdb on. (Might use it on a target system,
but the target system probably won't need gdb installed.) Bug filed.
hoichess Recommends: xboard >= 4.2.7-1 | scid
I'd guess that far more users have hoichess installed as a dependency of
gnome-games (which includes its own frontend) than use it with xboard or
scid. Bug filed.
inkscape Recommends: libgnomevfs2-extra
How would people know if they need this or not? It also doesn't seem to
have particularly excessive dependencies, and those it does have are
already pulled in by other paths. Perhaps this should just become part
of libgnomevfs2 by default?
kdenlive Recommends: dvgrab
kdenlive Recommends: recordmydesktop
Does kdenlive have integrated support for these, or are they just a way
to obtain video for subsequent editing? If the former, perhaps the
package description should document the need for the Recommends; if the
latter, they should become Suggests.
libcanberra-gtk3-0 Recommends: libcanberra-gtk3-module
How would people know if they need this or not?
[Skipping most of the library packages that have Recommends on -common
or -bin packages; most of those seem like they should either be Depends
or Suggests.]
libreoffice-base Recommends: default-jre | openjdk-8-jre | openjdk-7-jre | openjdk-6-jre | gcj-jre | sun-java5-jre | sun-java6-jre | java5-runtime | jre
How would people installing libreoffice know if they need a JRE or not?
libreoffice-base-drivers Recommends: libreoffice-sdbc-firebird
libreoffice-base-drivers Recommends: libreoffice-sdbc-hsqldb
This seems really unlikely.
libtool Recommends: libltdl-dev
Unlikely that most users (using it as a build tool) need this.
libuuid1 Recommends: uuid-runtime
Unlikely that most systems pulling in libuuid1 as a dependency need
this.
qemu-utils Recommends: sharutils
https://bugs.debian.org/820449
Reply to: