On Fri, Aug 1, 2014 at 5:21 PM, Jonas Smedegaard <d...@jones.dk> wrote:
Hi,
Quoting Christopher James Halse Rogers (2014-08-01 05:47:25)
On Thu, Jul 31, 2014 at 5:43 PM, Petter Reinholdtsen
<p...@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.
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
binaries.
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.
--
To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1406878866.2327...@mail.cooperteam.net
