Marius Mauch

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?

- 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)?

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

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

- how/where should sets be stored/distributed?

So, it's been a while since my last post, so people may wonder what happened since then within portage. Well, besides the usual maintenance releases of 2.1.2 there hasn't been a lot of exciting stuff as I've been mostly inactive, but there are still a number of interesting things:
- We've decided that trunk will be released as 2.2, not 2.1.3, due to the structural changes in the codebase (which aren't complete yet)
- I've finished Alecs work on the portage implementation of Glep 42 and added Portage support to the eselect module that was shipped with Paludis and made it compliant with the Glep, now we just have to wait for the eselect and Paludis people to get their act together for the module to be released (bug 179064)
- The new preserve-libs feature is now more or less complete except for the support in revdep-rebuild (more on this in a later post)
- KEYWORDS="-*" is now completely unsupported, gvisible() will throw a warning if it encounters packages using it (see KEYWORDS.stupid for reasons)
- Zac merged the license visibility code (aka ACCEPT_LICENSE)
- lots of other minor things Zac merged that I don't remember now, but most of those are also in 2.1.2
- I've added some basic instructions to our project page how interested people can use/test portage versions or svn without having to install them system-wide

There are still a lot of things I'd like to do, but most of those have been on the todo list for so long that it's unlikely to get them into 2.2, as my time and motivation is quite limited these days.