Re: [gentoo-dev] Sets in the tree

[Ciaran McCreesh]

On Wed, 14 Aug 2013 20:57:57 +0200
Tom Wijsman <TomWij@g.o> wrote:
> On Wed, 14 Aug 2013 19:09:40 +0100
> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
> > Er, look at the first post in the thread:
>
> That was about the repository, not about the PMS; the question was
> whether we need to respect the PMS

Ask yourself this: if it were a Paludis-specific feature not covered by
PMS instead of a Portage-specific feature not covered by PMS, would you
be happy with it being put in the main tree? If the answer is no, then
it shouldn't be in the tree.

> and why it misses this _feature_, for which no proposed specification
> exists afaik, so I don't see why you quote that implementation as a
> reason for it not being in the PMS.

It's not in PMS because no-one's finished the usual process for getting
it into PMS.

> > In order for sets to be added to the tree, we need a spec, we need
> > to decide where sets are allowed (package.mask?), and we need an
> > implementation.
>
> Sets in package.mask sounds unreliable as that would prohibit the set
> from being changed as long as it masked; unless of course, the
> specification would allow for a concept like "mask sets" to exist
> where a particular set is denoted as masked. Otherwise, you would have
> people add / remove things from a normal set and break the mask
> intent.

Using the conventional view of what a "set" is, the point is to allow
you to mask, say, kde7 using a single line, and then define what kde7
is using a set. Then the user can unmask kde7 without having to copy a
big, potentially changing list of packages out of package.mask.

Now, if you're viewing a set as being a metapackage rather than a list
of specs, this doesn't apply. But then why have sets at all if they're
just a metapackage?

-- 
Ciaran McCreesh