On Tue, Jun 06, 2017 at 09:06:46AM -0700, Russ Allbery wrote: > Adam Borowski <kilob...@angband.pl> writes: > > > More seriously, though, let's go through the list of 94 unsatisfied ones > > on my desktop; the list below is transposed to collate recommendees. > > And what happens here is, I think, typical: any one person often thinks > choices of recommends make no sense, but a broader perspective provides > quite a bit of justification.
It is remarkable that out of 94 unsatisfied recommends on my system you disagreed with just 6, despite them going contrary to the maintainer's wishes thus being certain to be controversial. Also, it's quite obvious this list was very hastily done, with often just a few seconds per entry. Thus, I admit the list does contain inaccuracies that fail when confronted with a bit more research. The intent is just to have a sample -- not to file actual bugs yet. > A good example: > > > dnsmasq-base: lxc > > * BAD: how often are you on a network without a DNS server? > > Your question here indicates to me that you've missed the point of this > dependency entirely. lxc uses the dnsmasq program (not service, hence > -base) for *DHCP* for containers on the container network. I do use lxc quite heavily, usually choosing IP addresses within config files but sometimes using DHCP. And it seems to work just fine without dnsmasq -- thus, unless I'm missing something, it's not something that "would be found together [...] in all but unusual installations". > If you do a search for lxc dnsmasq, you'll see tons of justification for > this Recommends. lxc is already pulling in tons of stuff; it would be > dumb to make it harder to use by omitting this small recommends of a few > binaries. 906kB is bigger than most of Recommends on this list, but as not a part of the default install you do have a point that it may make it easier to have pre-installed: while it's a common setup to store a lxc host on a separate small filesystem, typical lxc boxes aren't on the small side overall. I'm not persuaded about the importance of this add-on, but that's exactly why we're having this debate. The point of a debate is not to "win" but to find the best solution... > > gsfonts: libmagickcore-6.q16-3 libwmf0.2-7 > > * BAD: see ghostscript > > Your concept of what file formats are obsolete is not even remotely > similar to mine. I did not happen to know ghostscript can also be used not for .ps but also for some .pdf workflows (I prefer to not use blatantly fake-free software) but my main point stands: an _image_ manipulation program cannot be said to import _documents_ in "all but unusual installations". And "gsfonts" is not even ghostscript itself but merely an add-on for it. > > libgnomeui-0: xscreensaver > > * BAD: Gnome users won't run xscreensaver > > What? The hell they won't. There's gnome-screensaver, which has better integration with Gnome at the cost of using a ton of gnome-related bloat (which doesn't hurt a Gnome user in any way -- they already have that installed). Thus, a _typical_ Gnome user won't install xscreensaver, and a typical xscreensaver user won't install Gnome. And "Recommends:" is all about typical use. Plus, as Simon McVittie mentioned, libgnomeui-0 is strongly deprecated even within Gnome itself. > > libmail-sendmail-perl: po-debconf > > * BAD: why would po stuff want to send mail? > > This is for podebconf-report-po. I assume you've not packaged something > with translations? I'm not dealing with any po-heavy packages at the moment, yeah. It might indeed be useful for some deep po stuff, but the package I want is "debhelper". Technically, I do know how to package without debhelper (see "goodbye") but I still would prefer to use it. And as someone involved in both QA and sponsoring -- thus dealing with hundreds of packages -- I have yet to use podebconf-report-po once. Thus, it's quite hard to say that debhelper and libmail-sendmail-perl "would be found together in all but unusual installations". > > libpam-systemd: xfce4-power-manager xfce4-session > > * BAD: Depends:systemd, utterly pointless without it. > > This is a whole other discussion, but we had *endless* discussions of > this, and there are very sound technical reasons for structuring the > dependency chain this way. Let's not waste too much time right now, but if I recall that discussion correctly, the sane way would be to have a non-systemd alternative _first_: on a systemd install, the second alternative would be already present and thus satisfy the dependency, while the first one would avoid imposing systemd when not wanted. > > libpurple-bin: libpurple0 > > * BAD: a library has no reason to install programs > > This, like all other lib*-bin packages in Debian, are external helper > utilities *run by the library* under specific situations, which are split > into a separate package to avoid SONAME issues. Nope, its contents are four misc "extra utilities" that are mean to run _by the user_ or at most by some scripts. They look somewhat useful (purple-remote allows controlling pidgin from cmdline, etc) but are seriously hampered by a lack of documentation. On the other hand, not a single one is ever called by the library: strings `dpkg -L libpurple0`|grep purple-remote strings `dpkg -L libpurple0`|grep purple-send strings `dpkg -L libpurple0`|grep purple-send-async strings `dpkg -L libpurple0`|grep purple-url-handler As for your claim that "like all other lib*-bin packages in Debian", let's check the rest on my list: libpng-bin: usr/bin/png-fix-itxt usr/bin/pngfix libwmf-bin: usr/bin/wmf2{eps,fig,gd,svg,x} strings `dpkg -L libwacom2`|grep libwacom-list-local-devices > This is an entirely correct packaging strategy for optional library APIs > (in this case, things like opening remote URLs). > > I'm going to stop here, since at this point I think this is just going to > turn into a thread educating you about Debian packaging conventions you've > apparently not encountered before, which is really not a good use of > everyone's time. Uhm... could you be please be a bit more civil? Especially when making statements that are easily debunked (like the bit about "packaging conventions" of lib*-bin above). Somehow, neither Jonas nor Tom used a single angry word. And, their responses were informative even when I'm disagreeing with them. > I am completely unconvinced that there is any real problem here. That we're having another repeat of this thread, and that people tend to use --no-install-recommends despite that being supposed to be exceptional, says otherwise. > There are doubtless some bugs, most of them minor, in our separation > between Recommends and Suggests, and there's probably some opportunity to > craft better language to guide packagers to do the right thing, but mostly > there's an opportunity for people to file a few bugs after a *thoughtful* > analysis of package Recommends and why they might be there. The issue is systematic, and we have far more than "a few" cases. The very post you're responding to had 94 of them, and my desktop has only a small slice of packages in Debian installed -- and I looked at Recommends I have currently unfulfilled, there's far more where I either did not have the time to micromanage or have package B installed not because of Recommends from A but because of a dependency from C. > There certainly doesn't seem to be a problem large enough to warrant TC > involvement. TC would be an appropriate venue for a conflict with a _single_ maintainer, which is not the case here. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away. ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after ⠈⠳⣄⠀⠀⠀⠀ nearly two years of no catch!)