On Thu, 28 Jun 2007 21:03:54 -0700 Ned Ludd wrote: > 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. Well, mind that a very simple alias implementation as outlined above would for example unmerge kdepkg3 even if it was merged explicitly. > > - 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 about config files (package.*) or other sets? > > - 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. Simple: the list of atoms would be assembled dynamically by checking the available GLSAs, similar to how the "affected" target works in glsa-check. But lets keep the backend implementation details out for now. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better.