The mask for >=sys-apps/portage-2.2_pre says it will be masked until 2.1.6 is marked stable. It has been marked stable so the mask should probably be removed.
It's not for all arches. Adding a blocker.
There are a number of known bugs in the package sets and preserve-libs features. I plan to have a lot of these bugs fixed before I unmask it. I've updated the message in package.mask to reflect this.
(In reply to comment #2) > There are a number of known bugs in the package sets and preserve-libs > features. I plan to have a lot of these bugs fixed before I unmask it. I've > updated the message in package.mask to reflect this. Zac, what bugs are you referring to? Any bug numbers instead of or in addition to the following tracker bugs? bug #210077: [TRACKER] sys-apps/portage-2.2 bug #144480: [TRACKER] portage package set support bug #240323: [TRACKER] portage preserve-libs and @preserved-rebuild
There are some bugs that block bug 144480 and bug 240323, but there are some other issues that don't have bugs filed. Here are some that come to mind: 1) For preserve-libs, there is no protection against building packages which depend on packages for which libs are still preserved. This issue is briefly discussed here: http://blog.flameeyes.eu/2008/06/30/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour 2) Package set operators currently operate on atoms, but what users really need is for them to operate on the packages themselves. This will allow one set to add or subtract packages from another even though the sets to not use the exact same atoms to refer to the given packages. 3) The dependency resolver currently expands all the sets nested within a given set, and in the process discards the nesting relationship. Instead, it should keep the sets separate so that when a given nested set dependency is unsatisfied it's possible to indicate precisely which set is at fault.
(In reply to comment #4 > 2) Package set operators currently operate on atoms, but what users really need > is for them to operate on the packages themselves. This will allow one set to > add or subtract packages from another even though the sets to not use the exact > same atoms to refer to the given packages. I imagine the way this should be done is to create a mapping of atom -> package for each set, perform the intersection using the packages, and then map the package intersection back into a set of atoms.
(In reply to comment #4) > 2) Package set operators currently operate on atoms, but what users really need > is for them to operate on the packages themselves. This will allow one set to > add or subtract packages from another even though the sets to not use the exact > same atoms to refer to the given packages. In svn r13787 I've removed set operator support, since the current implementation will not meet user expectations. We can consider adding support for it again later, but the implementation will have to be entirely different.
In svn r14679 I've removed support for 'extend', 'remove', and 'intersect' sets.conf section attributes, for the same reasons as in comment #6.
*** Bug 344517 has been marked as a duplicate of this bug. ***
This is fixed with portage-2.2.0.
