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 > -- [EMAIL PROTECTED] mailing list
