Re: Reduce libcolord2 recommends on colord to suggests?
On Fri, Aug 1, 2014 at 5:21 PM, Jonas Smedegaard <email@example.com> wrote:
Quoting Christopher James Halse Rogers (2014-08-01 05:47:25)
On Thu, Jul 31, 2014 at 5:43 PM, Petter Reinholdtsen
[Christopher James Halse Rogers]
I'm somewhat leary of reducing the strength of the dependency for
temporary installability problem; colord meets the requirement of
“should be present on all but unusual configurations” when
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),
believe it do not make sense to say that colord should be present
all but unusual configuration for all these packages. Do you
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
My feeling is that a fairly significant number of GTK+ applications
use the printing infrastructure, and so, although it's not useful
*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
¹) only when e.g. a library would *crash* when a binary is
should the library recommend/depend on that binary.
What you include into your reasoning is a _chain_ of relationships:
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
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
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.