-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

This is a revised version of the profile EAPI lables proposal which
has been discussed previously [1].

Please consider a new 'eapi' profile configuration file that will
designate the EAPI to which any package atoms within the files of a
given directory of a profile stack must conform. This will allow
package managers to bail out with an informative error message if
the user accidentally selects a profile containing an EAPI that is
not supported by the currently installed package manager.

In order to allow a mixture of EAPIs in the profiles, each directory
of the profile stack may contain an 'eapi' configuration file to
indicate the EAPI for files contained within that specific
directory. In order to simplify things and avoid confusion, the EAPI
will never be inherited. Therefore, the EAPI assigned to a given
directory is assumed to be 0 if that directory does not explicitly
contain an 'eapi' configuration file. In addition to the profiles
themselves, the root profiles/ directory may also contain an 'eapi'
configuration file, since that directory contains 'package.mask' and
'info_pkgs' files which contain dependency atoms.

The format of the configuration file is very simple, containing only
the EAPI value on the first line and nothing more. For example, a
file containing just a single "0" character, followed by a newline,
could be created at profiles/base/eapi in order to explicitly
declare that files in the profiles/base/ directory contain
dependency atoms that conform to EAPI 0. However, this particular
declaration would be redundant since the EAPI is already assumed to
be 0 if a given directory does not contain an 'eapi' configuration file.

Different directories within a given profile stack will be allowed
declare different EAPIs. For example, the base profile can remain at
EAPI 0 and can thus be shared between some older profiles that
conform to EAPI 0 (in all directories of the stack) and some newer
profiles that contain some directories which require EAPI 1 or EAPI
2. By allowing a mixture of directories with different EAPIs, the
intention is to promote code sharing such that it will be possible
to use a common base profile between older and newer profiles, yet
still be able to use new EAPIs in newer profiles.

Does this seem like a good approach? Are there any suggestions for
improvements or alternative approaches?

[1]
http://archives.gentoo.org/gentoo-dev/msg_b976702d0adcaa5ca5edd0d280f05000.xml
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjpUuEACgkQ/ejvha5XGaPGjACbBMTF2wvtfwwOkXVNv6cStQr/
iIIAn1v7DbGnYyuWgs2GVxwlOfqyFRl1
=MAsI
-----END PGP SIGNATURE-----