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

Re: Reduce libcolord2 recommends on colord to suggests?

On Fri, Aug 1, 2014 at 5:21 PM, Jonas Smedegaard <dr@jones.dk> wrote:

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

Hm. I've not seen this view expressed before. Do you have any authoritative reference, or is this a synthesis of conversations over time?

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

I actually don't see why this would be a problem (modulo xwayland not being interesting, and using a virtual wayland-compositor package instead). The library is offering its functionalities to the binary, but *has* no functionality unless its corresponding daemon is running.

Reply to: