Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 204493

Summary: /etc/portage/package.* should support package sets
Product: Portage Development Reporter: Arfrever Frehtes Taifersar Arahesis (RETIRED) <arfrever>
Component: Core - ConfigurationAssignee: Portage team <dev-portage>
Severity: enhancement CC: ciaran.mccreesh, gent.8.madblock, graaff
Priority: High    
Version: 2.2   
Hardware: All   
OS: All   
Package list:
Runtime testing required: ---
Bug Depends on: 244366    
Bug Blocks: 144480    

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. ***