Bug 272488 – Please implement PROPERTIES="set" feature

• Product: Portage Development
• Status: CONFIRMED ---

[Description Maciej Mrozowski 2009-06-03 19:50:19 UTC]

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

[Comment 1 Maciej Mrozowski 2009-08-04 23:13:26 UTC]

CC-ing KDE team for feedback