Web lists-archives.com

Re: Too many Recommends (in particular on mail-transport-agent)

>>>>> Adam Borowski <kilobyte@xxxxxxxxxx> writes:
>>>>> On Mon, Jun 05, 2017 at 05:39:41PM -0700, Russ Allbery wrote:

 >> Maybe someone has a list of things they view as Recommends inflation
 >> that have (a) been reported as bugs to the appropriate package
 >> maintainers, and (b) have been rejected by those package
 >> maintainers?  Those are the controversial ones that we'd need to
 >> talk about.


 > bash-completion: bash dput-ng licensecheck

 > * DEBATABLE: I like the Tab key to do something reasonable,
 > "bash-completion" means you never know what you'll get.

	FWIW, I agree wholeheartedly with this one.  (The only reason I
	don’t have ‘complete -r’ in my ~/.bashrc is that bash-completion
	is rarely if ever installed on the systems I frequently use.)


 > freedoom | game-data-packager: prboom-plus

 > * DEBATABLE: freedoom is too ugly to live, shareware Doom has assets
 > missing for running pretty much anything Doom-related (and AFAIK its
 > license forbids add-ons).  On the other hand, this is an excuse for
 > Doom engines in main.

	The latter seems like a good enough reason for this dependency.

 > freepats: libwildmidi-config timidity

 > * BAD: freepats is too ugly to live: abysmal quality, lacks
 > instruments for pretty much any .mid file in the wild.  We do have a
 > bunch of good alternatives.  timgm6mb-soundfont for one is 5.6 times
 > smaller yet is complete.

	Probably a relic of the days long gone; I guess it should be
	updated to include some more alternatives (in preference to
	freepats) – so long as timidity can (be made to) actually use
	any of them “out-of-box.”

Package: freepats
Version: 20060219-1
Description-en: Free patch set for MIDI audio synthesis
 It is, however, the sole DFSG-compliant patch set in existence so far.
 New patches (including those in better formats, such as SF2 SoundFont banks)
 are welcome.


 > gfortran-mingw-w64: gcc-mingw-w64

 > * BAD: seriously, Fortran?

	Fortran is still widely used (in niche applications; WRF comes
	to mind), but I see no good reason for this dependency.

 > ghostscript: gimp imagemagick-6.q16 libmagickcore-6.q16-3 netpbm

 > * BAD: why would editing images care about a grossly obsolete
 > _document_ format?

	So that one can $ convert  pic.ps pic.png?  Or (I suspect)
	$ convert  file.pdf file.png, for that matter.

	(Or perhaps more sensibly: $ display  pic.ps pic.pdf.)

	Moreover, PostScript is a programming (code) language – not a
	(data) format.

	I’m neutral on this dependency, though.  I do like PostScript
	for a document format as much as I do like JavaScript for the
	same, but I see how it may be nice to support .ps (and .pdf?)
	rasterization in ImageMagick and Gimp “out-of-box.”


 > gnat-mingw-w64: gcc-mingw-w64

 > * BAD: see Fortran.


 > gnupg-l10n: gnupg

 > * DEBATABLE: I don't think anyone tech skilled enough to use GPG
 > would have problems with English, but localization is important.
 > On the other hand, this is 4.5MB in the default install.

	Well, ‘locales’ is about 9 MiB in the same, so…


 > libhtml-format-perl: libhtml-tree-perl libwww-perl

 > * ????: wut?

	… Me neither.

 > libhttp-daemon-perl: libwww-perl

 > * TRANSITIVELY BAD: dependency comes from a client package; if I want
 > to run a http server I know where to find it

	That’s only Installed-Size: 71, so I don’t see much of a
	problem.  AIUI, libwww-perl (as per upstream) had the
	HTTP::Daemon library for decades, thus not installing one by
	default in Debian may easily surprise an unsuspecting user.


 > libpackage-stash-xs-perl: libpackage-stash-perl

 > * TRANSITIVELY BAD: dependencies pulling more dependencies, why?

	I suppose that’s so one’s Perl script can be Architecture: all,
	instead of depending on either pure-Perl or an XS (binary)
	implementation of the package – depending on the architecture.


 > libpurple-bin: libpurple0

 > * BAD: a library has no reason to install programs

	My exact reaction on seeing that Mutt transitively Depends: on
	GnuPG – all thanks to libgpgme11 depending on the latter.

	I do not know about this specific case, but I very much agree
	with the principle.


 > libtasn1-doc: libtasn1-6-dev

 > * TRANSITIVELY BAD: probably useful if you do TASN (whatever it is),
 > pulled in by a very-widespread library (gnutls)

	That’s Abstract Syntax Notation One (or ASN.1), and while I use
	it all the time (notation, that is; not this specific library at
	the moment), I see no reason for a -dev package to depend on a
	-doc one any stronger than with a mere Suggests:.


 > transfig: inkscape

 > * BLOAT: a badly obsolete image format, pulls in ghostscript and
 > other crap

	Curiously enough, I still find XFig – with all its numerous
	shortcomings – more usable than Inkscape.


 > uuid-runtime: libuuid1 libuuid1:i386

 > * BAD: useful only if you generate many many UUIDs per second,
 > certainly unfit when coming from a transitively essential library

	… Me neither.

	Makes even less sense when installing libuuid1-depending
	software in a chroot – the one you do not intend to start
	daemons from, like, ever.


 > xml-core: libxml2 libxml2:i386

 > * BAD: what the heck I'd want a "XML catalog" for?

	To adequately process XML files with non-trivial <!DOCTYPE>s?

	AFAICT, the trend was to never ever rely on DTDs in newer XML
	formats and files, so this one’s only value is probably in
	enabling support for legacy XML.


FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A