[Merge] lp:~stgraber/indicator-power/revert-20130913 into lp:indicator-power

[Scott Kitterman]

On Saturday, September 14, 2013 23:17:48 Ted Gould wrote:
> On Sat, 2013-09-14 at 13:38 -0700, Steve Langasek wrote:
> > 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.
> 
> 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

>From policy 7.2:

Recommends This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found together with 
this one in all but unusual installations.

Suggests This is used to declare that one package may be more useful with one 
or more others. Using this field tells the
packaging system and the user that the listed packages are related to this one 
and can perhaps enhance its usefulness,
but that installing this one without them is perfectly reasonable.

I think Suggests is just fine here.

Scott K