| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Hi everyone, |
| 5 |
|
| 6 |
A number of people have been expressing desires to start using some |
| 7 |
new extensions in the portage tree [1]. Due to popular demand, I'm |
| 8 |
preparing a sys-apps/portage-2.1.3.12 release that will have support |
| 9 |
for EAPI="1". The extensions planned for inclusion are SLOT |
| 10 |
dependencies (#174405), IUSE defaults (#174410), and ECONF_SOURCE |
| 11 |
support for the default src_compile function (#179380). |
| 12 |
|
| 13 |
In order to accomplish this EAPI bump within a short time frame, |
| 14 |
I've intentionally restricted the list of extensions to those that |
| 15 |
are already implemented and relatively non-controversial [2]. We |
| 16 |
could wait longer and include more features in our first EAPI bump, |
| 17 |
but that route can lead to delays. Making a small bump now has the |
| 18 |
advantage of allowing useful new extensions to be used in the tree |
| 19 |
sooner. I expect sys-apps/portage-2.1.3.12 to be ready for release |
| 20 |
tomorrow (Friday) or the day after. |
| 21 |
|
| 22 |
An important thing to note is that repoman from any version of |
| 23 |
portage less than 2.1.3.12 will be unable to work with ebuilds that |
| 24 |
have EAPI="1" defined. If the EAPI is bumped even for just a single |
| 25 |
version of a package, the latest version of repoman will be required |
| 26 |
in order to generate a manifest for that package (which is required |
| 27 |
for something like a KEYWORDS change). Similarly, in order for |
| 28 |
repoman to do it's usual dependency QA checks, all dependencies need |
| 29 |
to be satisfied by packages that have supported EAPIs. These |
| 30 |
limitations are natural consequences that arises from that fact that |
| 31 |
portage can not support a given EAPI until that EAPI has been |
| 32 |
precisely defined. |
| 33 |
|
| 34 |
Package maintainers should carefully consider the consequences |
| 35 |
before defining EAPI="1" in the ebuilds for any packages that they |
| 36 |
maintain. Once >=sys-apps/portage-2.1.3.12 has stable KEYWORDS and |
| 37 |
all developers have upgraded, the above mentioned repoman |
| 38 |
limitations will cease to be relevant for the transition to EAPI="1" |
| 39 |
support. |
| 40 |
|
| 41 |
For those that may wonder how an EAPI bump will affect normal users, |
| 42 |
the answer it that it should be essentially transparent for them. |
| 43 |
When emerge encounters a package with an unsupported EAPI, it |
| 44 |
automatically masks it, much like it masks a package that doesn't |
| 45 |
have compatible KEYWORDS. Users will not be able to take advantage |
| 46 |
of a packages that use the latest EAPI until they have upgraded to a |
| 47 |
version of portage that supports it. Versions of portage >=2.0.54 |
| 48 |
support EAPI="0", and if the EAPI variable is undefined then it |
| 49 |
defaults to "0". |
| 50 |
|
| 51 |
Lots of people seem to be in favor of getting this first EAPI bump |
| 52 |
done as soon as possible. Additional feedback and questions are welcome. |
| 53 |
|
| 54 |
Zac |
| 55 |
|
| 56 |
[1] http://archives.gentoo.org/gentoo-dev/msg_148244.xml |
| 57 |
[2] http://archives.gentoo.org/gentoo-dev/msg_148270.xml |
| 58 |
-----BEGIN PGP SIGNATURE----- |
| 59 |
Version: GnuPG v2.0.7 (GNU/Linux) |
| 60 |
|
| 61 |
iD8DBQFHBWVL/ejvha5XGaMRAvVxAKCAbSRrstmRx7XXZEee6rU7JFsnUACfdH14 |
| 62 |
SH5hWyIlBfoN2wkg0xysI1Q= |
| 63 |
=DC+1 |
| 64 |
-----END PGP SIGNATURE----- |
| 65 |
-- |
| 66 |
gentoo-dev@g.o mailing list |
Archives