Quoting Christopher James Halse Rogers (2014-08-01 09:41:06) > 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> 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? What is authoritative is Debian Policy §7.2: > The `Recommends' field should list packages that would be found > together with this one in all but unusual installations. My interpretation emphasizes the lack of "and vice versa" in above quote. That in my experience matches how APT resolvers work. To paraphrase, your interpretation seem to imply an "and their reverse dependencies" in above quote. That causes problems like resolving the complex systemd transition which Petter used as example here. I have expressed similar view in the past: * https://bugs.debian.org/608807#10 ices2←libroar←libdnet←dnet-common * https://bugs.debian.org/612887#15 cmus←libroar←libdnet←dnet-common * https://bugs.debian.org/627083#15 libjack←jackd * https://bugs.debian.org/739783#5 ruby-bootstrap-sass←ruby-sass-rails * https://bugs.debian.org/750755#15 libmime-lite-perl←default-mta * https://bugs.debian.org/752797#20 libconfig-model-perl←fuse >> ¹) 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. Right, and same applies for libcolord: Its offer is "to talk to colord when running, else no fucntionality". Binaries needing colord should (have their package) suggest/recommend/depend on colord on their own. ...just as Wayland applications should suggest/recommend/depend on wayland on their own, not rely on libwayland to do it for them. - 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