Hi, 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 binaries. >> 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