-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everyone,
A number of people have been expressing desires to start using some
new extensions in the portage tree [1]. Due to popular demand, I'm
preparing a sys-apps/portage-2.1.3.12 release that will have support
for EAPI="1". The extensions planned for inclusion are SLOT
dependencies (#174405), IUSE defaults (#174410), and ECONF_SOURCE
support for the default src_compile function (#179380).
In order to accomplish this EAPI bump within a short time frame,
I've intentionally restricted the list of extensions to those that
are already implemented and relatively non-controversial [2]. We
could wait longer and include more features in our first EAPI bump,
but that route can lead to delays. Making a small bump now has the
advantage of allowing useful new extensions to be used in the tree
sooner. I expect sys-apps/portage-2.1.3.12 to be ready for release
tomorrow (Friday) or the day after.
An important thing to note is that repoman from any version of
portage less than 2.1.3.12 will be unable to work with ebuilds that
have EAPI="1" defined. If the EAPI is bumped even for just a single
version of a package, the latest version of repoman will be required
in order to generate a manifest for that package (which is required
for something like a KEYWORDS change). Similarly, in order for
repoman to do it's usual dependency QA checks, all dependencies need
to be satisfied by packages that have supported EAPIs. These
limitations are natural consequences that arises from that fact that
portage can not support a given EAPI until that EAPI has been
precisely defined.
Package maintainers should carefully consider the consequences
before defining EAPI="1" in the ebuilds for any packages that they
maintain. Once >=sys-apps/portage-2.1.3.12 has stable KEYWORDS and
all developers have upgraded, the above mentioned repoman
limitations will cease to be relevant for the transition to EAPI="1"
support.
For those that may wonder how an EAPI bump will affect normal users,
the answer it that it should be essentially transparent for them.
When emerge encounters a package with an unsupported EAPI, it
automatically masks it, much like it masks a package that doesn't
have compatible KEYWORDS. Users will not be able to take advantage
of a packages that use the latest EAPI until they have upgraded to a
version of portage that supports it. Versions of portage >=2.0.54
support EAPI="0", and if the EAPI variable is undefined then it
defaults to "0".
Lots of people seem to be in favor of getting this first EAPI bump
done as soon as possible. Additional feedback and questions are welcome.
Zac
[1] http://archives.gentoo.org/gentoo-dev/msg_148244.xml
[2] http://archives.gentoo.org/gentoo-dev/msg_148270.xml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHBWVL/ejvha5XGaMRAvVxAKCAbSRrstmRx7XXZEee6rU7JFsnUACfdH14
SH5hWyIlBfoN2wkg0xysI1Q=
=DC+1
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
Hash: SHA1
Hi everyone,
A number of people have been expressing desires to start using some
new extensions in the portage tree [1]. Due to popular demand, I'm
preparing a sys-apps/portage-2.1.3.12 release that will have support
for EAPI="1". The extensions planned for inclusion are SLOT
dependencies (#174405), IUSE defaults (#174410), and ECONF_SOURCE
support for the default src_compile function (#179380).
In order to accomplish this EAPI bump within a short time frame,
I've intentionally restricted the list of extensions to those that
are already implemented and relatively non-controversial [2]. We
could wait longer and include more features in our first EAPI bump,
but that route can lead to delays. Making a small bump now has the
advantage of allowing useful new extensions to be used in the tree
sooner. I expect sys-apps/portage-2.1.3.12 to be ready for release
tomorrow (Friday) or the day after.
An important thing to note is that repoman from any version of
portage less than 2.1.3.12 will be unable to work with ebuilds that
have EAPI="1" defined. If the EAPI is bumped even for just a single
version of a package, the latest version of repoman will be required
in order to generate a manifest for that package (which is required
for something like a KEYWORDS change). Similarly, in order for
repoman to do it's usual dependency QA checks, all dependencies need
to be satisfied by packages that have supported EAPIs. These
limitations are natural consequences that arises from that fact that
portage can not support a given EAPI until that EAPI has been
precisely defined.
Package maintainers should carefully consider the consequences
before defining EAPI="1" in the ebuilds for any packages that they
maintain. Once >=sys-apps/portage-2.1.3.12 has stable KEYWORDS and
all developers have upgraded, the above mentioned repoman
limitations will cease to be relevant for the transition to EAPI="1"
support.
For those that may wonder how an EAPI bump will affect normal users,
the answer it that it should be essentially transparent for them.
When emerge encounters a package with an unsupported EAPI, it
automatically masks it, much like it masks a package that doesn't
have compatible KEYWORDS. Users will not be able to take advantage
of a packages that use the latest EAPI until they have upgraded to a
version of portage that supports it. Versions of portage >=2.0.54
support EAPI="0", and if the EAPI variable is undefined then it
defaults to "0".
Lots of people seem to be in favor of getting this first EAPI bump
done as soon as possible. Additional feedback and questions are welcome.
Zac
[1] http://archives.gentoo.org/gentoo-dev/msg_148244.xml
[2] http://archives.gentoo.org/gentoo-dev/msg_148270.xml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHBWVL/ejvha5XGaMRAvVxAKCAbSRrstmRx7XXZEee6rU7JFsnUACfdH14
SH5hWyIlBfoN2wkg0xysI1Q=
=DC+1
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
