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.

	Agreed.

 > 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