Re: Opt out style recommends
On Fri, Apr 08, 2016 at 09:51:18PM +0200, Jonas Smedegaard wrote:
> Quoting Adam Borowski (2016-04-08 21:05:23)
> > On Thu, Apr 07, 2016 at 11:49:38PM -0400, Harlan Lieberman-Berg wrote:
> >> [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.
> >
> > To the contrary, I'd say Recommends chains have ran amok to the point
> > installing Recommends without thinking leads to insanity.
> >
> > When you install package X, its Recommends are indeed usually helpful.
> > The Recommends of a random library package X pulls almost never are.
>
> Please file bugs against libraries with too aggressive recommendations -
> that's the way forward (not avoiding recommendations altogether).
The problem here is that for the library itself the recommendation does make
sense. It's only when some user of the library gets pulled by a completely
unrelated package when the recommendation becomes bad. The dependency chain
involved can be very long -- are recommends supposed to change because
something on the other end of Debian changed?
Like:
xfce4-power-manager -> upower -> libimobiledevice4 -> usbmuxd
Is the recommendation from libimobiledevice4 to usbmuxd valid? Sure it is
-- the library is useless without the daemon.
Is the dependency from upower to libimobiledevice4 valid? It is -- using
dlopen for every optional feature would require massive amounts of work.
Is the dependency from xfce4-power-manager to upower valid? Certainly --
x-p-m is merely a GUI that needs upower for everything.
But, wanting to suspend my computer doesn't mean I own an iPod or want a
daemon that's useless for non-iPod-users!
Unfortunately, because of metapackages fixing this is not as easy as "obey
only direct recommendations". On the other hand, having a recommendation
suddenly become bad because of an unrelated change to an unrelated package
far away doesn't sound reasonable to me.
Is there an agreed-upon policy? Because I wouldn't want to start filing
hundreds or thousands of bug reports without a consensus.
And, many maintainers could take this as an attack: "what, my package is
useless?!?". Like, openssh-server -> libwrap0 -> tcpd. I'd say pretty much
anyone today uses other means for limiting access to ssh; tcpd does have
near-universal popcon (95.79%!) but protocols listed in its description
(telnet ftp rsh rlogin finger) and complete dearth of new bug reports (it
received tons in the past) make me think it's not actually used anymore.
But, to get the Recommends removed I'd need to wage such a war against every
maintainer of such a library package!
So, what about this rule:
"a library should not recommend/depend on non-libraries, the dependency
should come from actual programs or metapackages".
Thus, it'd be up to openssh-server to consider how strongly it suggests
tcpd, up to scanner software or maybe gnome-meta to pull in colord, up to
dose-extra not librpm3 to consider rpm, etc. Maintainers of libraries
tend to have grossly inflated view of importance of their software, so
I believe users of those libraries can provide more accurate
recommendations.
Meow!
--
A tit a day keeps the vet away.
Reply to: