On Tue, 16 May 2006 15:11:35 -0700
Zac Medico <zmedico@g.o> wrote:

> Yeah, I think what's really needed is a specification of what is
> allowed in gentoo's official portage tree.  Let's take "per-package
> use.mask" (bug 96368) as an example.  It could be implemented as
> package.use.mask or as package.mask + use deps.  Which will it be?
> Will paludis, pkgcore, and portage all handle this functionality the
> same way or not?  If we're going to allow new features such as this
> into the official portage tree, we need to make sure that they
> conform to a specification that everyone has agreed upon.

Sounds sane, as long as said specification can be extended within a
reasonable timeframe. Basing this specification on what Portage
currently supports, I would add:

* Multiple profile inheritance: the `parent' file contains a list, one
per line, of profiles to inherit, as a relative path from the current
directory. Profiles are loaded in the order listed, so that later
entries override previous ones, and the current profile overrides all.
If the package manager does not support multiple inheritance, only the
first line is read (from what I'm told, this is what Portage does
currently).

* Per-package use masking: The package.use.mask file contains, one
entry per line, '<dep atom> <flags to mask>'. These flags are then
masked as normal for any package matching the atom.

* USE forcing, global and per-package: Format is the same as for use
masking, but the flags are force-enabled instead of disabled. Files are
use.force and package.use.force.

* Dep atom extensions: Basic format is the same as current Portage,
with the following additions:
 - <atom>:<slot> -- SLOT must match the value given
 - <atom>::<repository> -- the package must be taken from the
repository with the given identifier.
 - <atom>[use] -- The package must be installed with the given use flag
enabled. For <atom>[-use] the flag must be disabled. Multiple [use]
restrictions in an atom are permitted, the syntax being
<atom>[use1][-use2][use3].

The rest of our extensions are wider in scope, so that's more or less
the list of non-portage-supported features we're looking at at the
moment. Note that the new dep syntax would not be used in any ebuilds,
but only at the profile level.

If anyone wants to codify the ebuild / profile format into a formal
specification, you have my full support as long as it is easily
extensible with anything new that Portage or other package managers may
support. Obviously such extensions should be discussed beforehand, but
they should be possible within a reasonable timeframe.
-- 
gentoo-qa@g.o mailing list