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

Re: Reduce libcolord2 recommends on colord to suggests?


Quoting Christopher James Halse Rogers (2014-08-01 05:47:25)
> On Thu, Jul 31, 2014 at 5:43 PM, Petter Reinholdtsen <pere@hungry.com> 
> wrote:
>> [Christopher James Halse Rogers]
>>> I'm somewhat leary of reducing the strength of the dependency for a 
>>> temporary installability problem; colord meets the requirement of 
>>> “should be present on all but unusual configurations” when you've 
>>> got libcolord2 installed.
>> When looking at the two packages in isolation, I have no doubt you 
>> are right.  But when seen from the more distant dependencies (like 
>> notification-daemon or any other package depending on libgtk-3-0), I 
>> believe it do not make sense to say that colord should be present on 
>> all but unusual configuration for all these packages.  Do you agree?
> Yes, for notification-daemon. Since colord is only used in printing 
> support, if we had a way to specify “Recommends: colord 
> (if_package_uses_gtks_printing_symbols)” then I'd certainly use that.
> My feeling is that a fairly significant number of GTK+ applications 
> use the printing infrastructure, and so, although it's not useful for 
> *all* rdepends of libgtk-3-0, I don't think it's unreasonable for 
> libgtk-3-0 to pull in colord.

Package dependencies, recommendations and suggestions are _directed_ 
graphs: libraries should generally¹ _not_ depend/recommend/suggest 
binaries, only the other way around.

¹) only when e.g. a library would *crash* when a binary is unavailable 
should the library recommend/depend on that binary.

What you include into your reasoning is a _chain_ of relationships: GTK+ 
applications which need colord for most of their usecases should 
recommend/depend on colord on their own.  If that means "most of them" 
it is not an argument for adding an _reverse_ relationship from the 
library, but instead an argument for GTK+ library to consider adding the 
relationship on behalf of its binaries.

GTK+ in Jessie also links against libwayland - but libwayland does not 
declare a relationship to xwayland or weston.  Not because Wayland is 
not yet popular (that would only be a shift from recommending to 
suggesting), but because a library is _offering_ its functionalities to 

>> This is a really generic problem affecting the Debian installer, not 
>> something specific to Debian Edu.
>> When Debian manage to switch to systemd, the issue will be hidden 
>> again.  So it is not a question of when Debian Edu migrate, it is a 
>> question of when we all in Debian migrate. :)
> I'm not sure that ‘hidden’ is the right word here. The problem is 
> precisely the in-progress transition to systemd.

The word "hidden" is IMO the right word in the context of Debian-Edu 
versus Debian timing of switch to systemd, but switch to systemd is not 
the issue we are discussing here - it is merely an example consequence 
of too strong package dependencies.

Hope that helps,

 - 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: