Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 204493 - /etc/portage/package.* should support package sets
Summary: /etc/portage/package.* should support package sets
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Configuration (show other bugs)
Hardware: All All
: High enhancement with 1 vote (vote)
Assignee: Portage team
: 204522 217543 (view as bug list)
Depends on: 244366
Blocks: 144480
  Show dependency tree
Reported: 2008-01-05 23:43 UTC by Arfrever Frehtes Taifersar Arahesis (RETIRED)
Modified: 2008-10-25 19:51 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 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) gentoo-dev 2008-01-05 23:49:10 UTC

*** This bug has been marked as a duplicate of bug 6411 ***
Comment 2 Zac Medico gentoo-dev 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) gentoo-dev 2008-01-11 02:17:31 UTC
*** Bug 204522 has been marked as a duplicate of this bug. ***
Comment 4 Marius Mauch (RETIRED) gentoo-dev 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) gentoo-dev 2008-06-10 22:33:44 UTC
*** Bug 217543 has been marked as a duplicate of this bug. ***