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

Re: Depends/Recommends from libraries

Quoting Russ Allbery (2017-03-09 04:24:09)
> 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).

What I believe could be improved in policy is to clarify/emphasize that 
package relations are _directional_.

I have reported several bugs related to too strong relationships, where 
the main arugment of mine was that the relationship more accurately was 
the reverse of what was declared.

That said, I agree it not not sensible to (yet) impose a strict rule, 
only a clarification to existing rules on declaring relationships.

> 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.)

What you describe above is how a _different_ software design could 
result in simpler package dependencies - for _existing_ software I find 
it correct to identify the libimobiledevice4 → usbmuxd relation as the 
problematic one.

> In general, I don't want to see us place too many restrictions on 
> Recommends.  If you don't want additional helpful programs, disable 
> installing Recommends by default.  I think it's very odd to worry 
> about bloat while simultaneously installing Recommends by default; 
> those aren't really consistent things to do.

I strongly disagree: We _can_ improve on the default behaviour of our 
package handling - we need not give up and leave it to power users able 
to handle arguably broken systems.

 - Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature

Reply to: