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