Bugzilla Bug 272488

Following the discussion:
http://archives.gentoo.org/gentoo-dev/msg_02020c2650449920c941adf46dbf7d6f.xml

and revised Zac Medico proposition:
http://archives.gentoo.org/gentoo-dev/msg_aeb57814a55bb7f8a389a45d87d9449b.xml

As member of KDE herd, providing support for meta packages (supported by
unmasked portage) and package sets (not flexible - not USE flags aware, not
SLOT aware) is redundant job, and none of them provides what we want to manage
multiple KDE releases in efficient manner.

Meta packages:
+ they are flexible (USE flags so optional dependencies, :${SLOT} deps and
other variables can be utilized)
+ they fit already in known atom syntax
- does not pull packages when --oneshot is used (and no --update) - useless for
rebuilding groups of live ebuilds
- does not support operators (intersections)

Sets (Portage 2.2_):
+ very useful in rebuilding groups of live packages
+ very useful in removal groups of packages
+ with intersections, they provide additional control
- syntax confusing for users
- no support for USE flags (enforce same kdeprefix=)
- 'wooden' - no ability to pull atoms conditionally (based on USE flag for
example: now try to set -kdeprefix for all KDE 4.2 apps but no KDE live...)
- they cannot be simply revbumped - they need manual PV/SLOT dependency
adjustments

PROPERTIES="set" seems to cover most pros of both solutions.
Adding intersection operator for such ebuilds could render current Portage sets
nearly obsolete (system defined sets could not be implemented by
PROPERTIES="set")

CC-ing KDE team for feedback