Re: [gentoo-portage-dev] [RFC] Properties of package sets

[Ned Ludd <solar@gentoo.org>]

On Fri, 2007-06-29 at 05:07 +0200, Marius Mauch wrote:
> Please reply on gentoo-portage-dev, _not_ on gentoo-dev, thanks.
> 
> One missing feature in portage is the lack of package sets. Before we
> (re)start working on that however I'd like to get some feedback about
> what properties/features people would expect from portage package set
> support.
> Some key questions:
> 
> - should they simply act like aliases for multiple packages? E.g.
> should `emerge -C sets/kde` be equivalent to `emerge -C kdepkg1 kdepkg2
> kdepkg3 ...`? Or does the behavior need to be "smarter" in some ways?

I like the alias way acting simply as a metapkg.

> - what kind of atoms should be supported in sets? Simple and versioned
> atoms for sure, but what about complex atoms (use-conditional, any-of,
> blockers)?

Mixed feelings about this. At first I assumed the syntax would be that
pretty much of package.mask etc.. But I can for sure see the advantage
of something as tad more complex of use conditionals being handy.
USE="foo bar -nls" ROOT=/baz emerge sets/livecd.
with the file being defined as nls? ( dislike/gettext ) but at the same
time this is probably when we should use a proper ebuild as a metapkg.

> - should sets be supported everywhere, or only in selected use cases?
> (everywhere would include depstrings for example)

Please NO. emerge.py should know about sets but ebuild.py should be
oblivious to them. package sets as you are proposing imo should be
limited to portage only. By putting package sets in ebuild depstrings we
would be effectively forcing all other pkg managers to support the
feature. I don't think we should do that.


> - what use cases are there for package sets? Other than the established
> "system" and "world", and the planned "all" and "security" sets.

Assuming you guys run with with the simple alias method I don't see how
'security' can fit into this. 


> - how/where should sets be stored/distributed?
> 
> Please reply on gentoo-portage-dev, _not_ on gentoo-dev, thanks.
> 
> Marius
> 

-- 
gentoo-portage-dev@gentoo.org mailing list