[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Depends/Recommends from libraries

Am 09.03.2017 um 04:24 schrieb Russ Allbery:
> Adam Borowski <kilobyte@angband.pl> writes:
>> I'd like to discuss (and then propose to -policy) the following rule:
>> # Libraries which don't provide a convenient means of conditionally loading
>> # at runtime (this includes most libraries for languages such as C), SHOULD
>> # NOT declare a "Depends:" or "Recommends:" relationship, directly or
>> # indirectly, on packages containing anything more than dormant files. 
>> # Those include, among others, daemons, executables in $PATH, etc.  Any such
>> # relationship should be instead declared by programs that use the library
>> # in question -- it is up to them to decide how important the relationship
>> # is.
> This feels to me like the wrong tool.  It's entirely plausible for there
> to be a library whose entire purpose is to execute some external helper
> program with elevated privileges, which obviously should depend on the
> package that provides that program.  If we had such a requirement in
> Policy, we would end up with libraries that don't Depend on their actual
> dependencies and then callers have to add the dependency and then it's all
> just a mess.
> I feel like the problem here is that people are failing to fix bugs in
> their packages (unnecessary dependencies on libraries that have heavy
> dependencies), and you're trying to use Policy as a stick to beat them
> with to get them to fix their bugs.  I don't think this is a good idea,
> and I don't want us to end up with weird and incorrect dependencies for
> libraries that really do require external helper programs (which is not
> particularly rare).
> Particularly since I don't think this requirement is actually targeted at
> the dependency that's bothering you.  In your example:
>> It'd help disarm dependency chains such as:
>>     xfce4-power-manager -> upower -> libimobiledevice4 -> usbmuxd
>> ie, wanting XFCE currently pulls in a daemon that's of no use to anyone not
>> using a piece of iJunk (and what it even has to do with power management?).
> this would outlaw the Recommends from libimobiledevice4 to usbmuxd, but my
> understanding is that dependency is *correct*, and the actual extraneous
> dependency that's upsetting you is the one from upower to
> libimobiledevice4, which this Policy change would not affect at all.  If I
> were fixing this bug, that's the change I would make: have upower
> dynamically load libimobiledevice4 iff it exists, since that's fairly
> niche functionality.  (Or, really, given that it's a Recommends, just not
> worry about it.)

As the question was asked why upower links against libimobiledevice4: it
is to support Apple hardware and get the battery state from those devices.

usbmuxd is hardware activated via a udev rule, so there is no extraneous
running daemon unless the hardware is plugged in.
Disk space is rather cheap and I prefer if hardware is just supported
out of the box. Unfortunately we don't have a well supported mechanism
which would install such hardware-enablement packages when the hardware
is plugged in.

Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: