| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Hi everyone, |
| 5 |
|
| 6 |
This is a revised version of the profile EAPI lables proposal which |
| 7 |
has been discussed previously [1]. |
| 8 |
|
| 9 |
Please consider a new 'eapi' profile configuration file that will |
| 10 |
designate the EAPI to which any package atoms within the files of a |
| 11 |
given directory of a profile stack must conform. This will allow |
| 12 |
package managers to bail out with an informative error message if |
| 13 |
the user accidentally selects a profile containing an EAPI that is |
| 14 |
not supported by the currently installed package manager. |
| 15 |
|
| 16 |
In order to allow a mixture of EAPIs in the profiles, each directory |
| 17 |
of the profile stack may contain an 'eapi' configuration file to |
| 18 |
indicate the EAPI for files contained within that specific |
| 19 |
directory. In order to simplify things and avoid confusion, the EAPI |
| 20 |
will never be inherited. Therefore, the EAPI assigned to a given |
| 21 |
directory is assumed to be 0 if that directory does not explicitly |
| 22 |
contain an 'eapi' configuration file. In addition to the profiles |
| 23 |
themselves, the root profiles/ directory may also contain an 'eapi' |
| 24 |
configuration file, since that directory contains 'package.mask' and |
| 25 |
'info_pkgs' files which contain dependency atoms. |
| 26 |
|
| 27 |
The format of the configuration file is very simple, containing only |
| 28 |
the EAPI value on the first line and nothing more. For example, a |
| 29 |
file containing just a single "0" character, followed by a newline, |
| 30 |
could be created at profiles/base/eapi in order to explicitly |
| 31 |
declare that files in the profiles/base/ directory contain |
| 32 |
dependency atoms that conform to EAPI 0. However, this particular |
| 33 |
declaration would be redundant since the EAPI is already assumed to |
| 34 |
be 0 if a given directory does not contain an 'eapi' configuration file. |
| 35 |
|
| 36 |
Different directories within a given profile stack will be allowed |
| 37 |
declare different EAPIs. For example, the base profile can remain at |
| 38 |
EAPI 0 and can thus be shared between some older profiles that |
| 39 |
conform to EAPI 0 (in all directories of the stack) and some newer |
| 40 |
profiles that contain some directories which require EAPI 1 or EAPI |
| 41 |
2. By allowing a mixture of directories with different EAPIs, the |
| 42 |
intention is to promote code sharing such that it will be possible |
| 43 |
to use a common base profile between older and newer profiles, yet |
| 44 |
still be able to use new EAPIs in newer profiles. |
| 45 |
|
| 46 |
Does this seem like a good approach? Are there any suggestions for |
| 47 |
improvements or alternative approaches? |
| 48 |
|
| 49 |
[1] |
| 50 |
http://archives.gentoo.org/gentoo-dev/msg_b976702d0adcaa5ca5edd0d280f05000.xml |
| 51 |
- -- |
| 52 |
Thanks, |
| 53 |
Zac |
| 54 |
-----BEGIN PGP SIGNATURE----- |
| 55 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 56 |
|
| 57 |
iEYEARECAAYFAkjpUuEACgkQ/ejvha5XGaPGjACbBMTF2wvtfwwOkXVNv6cStQr/ |
| 58 |
iIIAn1v7DbGnYyuWgs2GVxwlOfqyFRl1 |
| 59 |
=MAsI |
| 60 |
-----END PGP SIGNATURE----- |
Archives