Am 09.03.2017 um 04:24 schrieb Russ Allbery: > Adam Borowski <kilob...@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?
signature.asc
Description: OpenPGP digital signature
