<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6"> </HEAD> <BODY> On Sat, 2013-09-14 at 13:38 -0700, Steve Langasek wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Sat, Sep 14, 2013 at 01:43:00PM -0600, Adam Conrad wrote: > On Sat, Sep 14, 2013 at 08:58:49AM -0500, Ted Gould wrote: > > I understand your concern about bringing in additional packages onto the > > desktop image. What I don't agree with is removing the feature from > > indicator-power instead of figuring out the issues with all of those > > packages being brought onto the image. The issue is that > > liburl-dispatcher1 recommends url-dispatcher, as is customary on > > libraries that implement the interface of a service. > Is this actually "customary"? In what circles? I've actually fought > pretty hard in the past to *not* have libraries depend on external > services, daemons, and random binaries, because linking to a library > doesn't necessarily mean every user of your application wants to use > every last plugin/service/etc available to it. > I'd think a Suggests is perfectly reasonable, and explicitly seeding > in tasks (touch, perhaps eventually desktop) where you want that bit > to do something other than be a dormant library dependency. I agree. I don't think there's anything "customary" about libraries recommending the service they interface with; I think that gives buggy semantics. If the service is not available, the library should fail gracefully anyway, so if you want to ensure the service is present that should be handled with a higher-level dependency, *not* via a dependency from the library. </PRE> </BLOCKQUOTE> Hmm, okay. I'm not against that, but it does counter my intuition about what the various levels of dependency are. I would describe them like like this: Requires: Things will break if you don't have it Recommands: Eh, things won't break but it won't really work without this Suggests: These are things that might be helpful as well Is there something I'm missing here? More importantly, let me ensure that the course of action for indicator-power is clear. I will change liburl-dispatcher to Suggest url-dispatcher. Then I will add dependency to indicator-power for liburl-dispatcher. That way there shouldn't be the whole click upstart-app-launch set of dependencies pulled onto the desktop image, and the touch seed should contain url-dispatcher. Thanks, Ted </BODY> </HTML>