On Sat, 04 Oct 2008 03:46:41 +0000
"Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]> wrote:

> It would also be important to have versioned sets (depending on a
> slot, for example). Marius Mauch (genone) suggested a very
> interesting way to solve this by using a set config file (portage
> specific) that, as he stated, "should work if I got the syntax right
> from memory" [current Portage svn] (something similar to):
> 
> - ---- sets.conf ----
> [slot-4.1]
> class=dbapi.VariableSet
> variable=SLOT
> include=4.1
> 
> [kdebase]
> class=files.StaticFileSet
> filename=kdebase
> 
> [kdebase-4.1]
> class=base.DummyPackageSet
> extend=kdebase
> intersect=slot-4.1

Small correction: The example above doesn't actually work as intended,
as the VariableSet handler only operates on installed packages, so 
@kdebase-4.1 would actually contain atoms that are
- listed in @kdebase
- have SLOT=4.1
- are already installed

> - ---- sets.conf ----
> 
> Being able to take advantage of use deps for packages would be a
> bonus: kde? (
>     x11-libs/compizconfig-backend-kconfig
>     x11-wm/compiz[kde]
> )

Basic use deps are supported (those that don't expand to use
conditionals), use conditionals are not, and probably won't be for
various reasons.

> It would be really helpful if we could have a "package.mask" like
> structure that allowed users to "mask" deps from sets (does / could
> package.mask be used this way?)

Well, portage has a set handler for wrapping /etc/portage/package.*
files in sets, which in combination with the substraction operator /the
"remove" option in sets.conf can be used for this purpose.

> Perhaps we should start doing "emerge -uDav @world/@installed".

What would be the point of that?

> So this is what I would like to see with sets. Am I crazy? Is it
> possible to do any of this? Anyone has some other needs?      

Well, pretty much all what you want is possible with current portage
codebase (only available via svn, not released yet), except for use
conditionals, and the issue about VariableSet mentioned above, but
that's fixable in several ways. Mind that details of the examples above
might change over time as that stuff is just a few days old.

Using that stuff in the tree however is a completely different issue,
as the current sets.conf format will likely never be supported by other
package managers than portage (as it's somewhat tied to the portage
API).

Marius

Reply via email to