Bug 204493 – /etc/portage/package.* should support package sets

• Product: Portage Development
• Status: RESOLVED CANTFIX

[Description Arfrever Frehtes Taifersar Arahesis (RETIRED) 2008-01-05 23:43:02 UTC]

It would be very useful if /etc/portage/package.* files could support package sets.

I think that the good syntax would be:
@package_set flag_1 flag_2 ... flag_N

[Comment 1 Jakub Moc (RETIRED) 2008-01-05 23:49:10 UTC]

*** This bug has been marked as a duplicate of bug 6411 ***

[Comment 2 Zac Medico 2008-01-11 00:38:48 UTC]

I think we should keep this bug separate to track the feature since much of bug #6411 is already implemented.

[Comment 3 Marius Mauch (RETIRED) 2008-01-11 02:17:31 UTC]

*** Bug 204522 has been marked as a duplicate of this bug. ***

[Comment 4 Marius Mauch (RETIRED) 2008-01-11 02:27:28 UTC]

Unfortunately this is between hard and impossible to do for two reasons:

1) API issues: 
To build package sets, the SetConfig class need a config instance (as well as vardbapi and portdbapi). To allow sets in package.* files the config class needs a SetConfig instance, at best within the constructor, so we have a very nasty circular dependency here. Could be elevated somewhat by requiring the caller to "update" the config instance by calling a new method, but it's still quite nasty, and doesn't fix the second problem.

2) requires multi-pass processing:
Some sets make use of visibility filtering. In the future some sets may contain USE conditionals. If we allow package sets to influence visibility filtering and $USE we have to regenerate both package sets and config instances until the results don't change anymore, or get extremely confused users/bugreports (it's somewhat like autouse)

The second issue might be solved by only allowing sets in package.* that aren't influenced by package.*, but that restricts the usefulness of such a feature, the potential of package sets in general and might be hard to communicate to users.

So unless someone has a really bright idea how to overcome these issues I consider this as CANTFIX (I'd really like to implement this though if it would be possible in a sane way)
Also for static file-based package sets and package.{mask,unmask,keywords} it's unneccessary as you can create those as dirs and create a symlink to the package set as they currently use the same syntax, might even extend the syntax of sets to be compatible with package.use as well.

[Comment 5 Ciaran McCreesh 2008-01-11 09:51:59 UTC]

You need to handle 2) in some way for use deps anyway... Paludis does it by banning them in use.conf. Otherwise you're left with the fun task of deciding what foo/bar[foo] -foo does.

[Comment 6 Marius Mauch (RETIRED) 2008-06-10 22:33:44 UTC]

*** Bug 217543 has been marked as a duplicate of this bug. ***