[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Recommends for metapackages



On 12-07-10 at 10:07pm, Eugene V. Lyubimkin wrote:
> On 2012-07-10 20:15, Jonas Smedegaard wrote:
> > On 12-07-10 at 07:35pm, Eugene V. Lyubimkin wrote:
> > > On 2012-07-10 18:10, Jonas Smedegaard wrote:
> > > > The very purpose of a meta-package is to _ensure_ that a certain 
> > > > set of packages is installed, not just recommend them: All (not 
> > > > only most) users of that package need all its dependencies 
> > > > satisfied
> > > 
> > > My definition of meta-package is less strict than yours. I as user 
> > > sometimes want '[meta]package X, but without packages Y and Z', 
> > > and your definition absolutely rules that out.
> > > 
> > > I saw many questions on forums like
> > > 
> > > "I did '$packagemanager install $metapackage' and then after 
> > > '$packagemanager remove $singlepackage', why $packagemanager now 
> > > wants to remove all $metapackage?"
> > > 
> > > , so I know I'm not alone.
> > 
> > [...]
> > You being alone does not make you right.
> > 
> > A package manager wanting to remove all dependencies of a 
> > meta-package is quite sensible - when you understand the sense of 
> > it.  Until then it is utterly confusing.
> 
> As someone who developed a high-level package manager for Debian from 
> scratch (including the autoremoval functionality) I'm pretty sure I 
> understand the sense of it.

Fair enough.  Sourry if it sounded like I was talking down to you, that 
wasn't my intention.  I simply meant to acknowledge that users can be 
confused - I sure have been (and problably still is about some things, 
time will - hopefully - tell).


> My message was: users who don't (yet) understand the full picture, 
> find that behavior confusing, and it takes time to explain. Moreover, 
> despite me understanding the picture, I still has no clean, safe and 
> documented way to do what I'd want in case the package maintainer 
> chosed Depends.

Acknowledged.


> Next, I don't pretend I'm "right", I do pretend there are >= 1 person 
> who don't need all dependencies of the metapackage installed, and 
> hence your 'All [...] users of that package need all its dependencies 
> satisfied' clause is wrong. You can argue that it's not right for 
> Debian to support that use case, that's fine.

I do support the use case of not needing all packages depended on by 
some meta-package.

My point was (and still is) that those should not use that meta-package: 
The users of a meta-package is the users of what the meta-package does, 
which is to pull in a certain set of other packages.

It might very well be that some other meta-packages has the different 
purpose of only _recommending_ a set of packages, but evidently this one 
does not.

No, I do not find it right for Debian to mandate meta-packages to only 
recommend when some users need only a subset of the offerings of said 
meta-package: There will _always_ be some users needing only a subset of 
things, rendering all dependencies "wrong" by that logic!

(...as has already been pointed out by others)


> > > Using Recommends for non-core parts of metapackages' dependencies 
> > > would nicely solve that.
> > 
> > ...but I disagree that making meta-packages more elastic is a "nice" 
> > solution: is a hack covering over misguided users.  Possible 
> > solutions could be improved documentation and improved design of 
> > package managers.
> 
> ... And I disagree with that. No solution can override policy's "all 
> Depends must be satisfied". If one choose to support the "exclude from 
> metapackage" one either has to change the policy, remove packages from 
> Depends or use non-stock metapackage (which I personally don't like).

You need not redefine "depends" to not mean "depends": Simply do not use 
that meta-package if you do not want _all_ its dependencies installed.


 - 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: Digital signature


Reply to: