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
