Hi, developers and users.
TLDR: if you do [${MULTILIB_USEDEP}] or [abi_x86_32], always use >= dep
on the oldest package version that is EAPI=5 or multilib. In other
words, the >= dependency must not match a single non-multilib, EAPI<5
ebuild. And please do not commit new EAPI<5 ebuilds following EAPI=5
ebuilds.
Long version:
First of all, I'd like to thank all supporters of our little multilib
effort. We're getting pretty close to finishing stage 1 of our roadmap
[1], with most of important packages being multilib-ready already [2].
Most of our effort right now is focused on fixing 32-bit package
dependencies [3].
However, it was lately brought to my attention that the very complex
issue regarding portage behavior wrt USE_EXPAND flags and EAPI<5. Since
PMS is awfully incomprehensible in this area, I won't get into the fine
details. The same issue was discussed wrt Python in bug #446720 [4].
The important part is that a dependency of the following form:
dev-foo/bar[abi_x86_64(-),abi_x86_32(-)...]
can be satisfied not only by multilib ebuilds. It is also satisfied by
EAPI<5 ebuilds that don't have abi_* flags in IUSE if the user has
enabled respective abi_* flags globally. In other words, if the user
has:
ABI_X86="32 64"
in his make.conf, portage thinks that all EAPI<5 packages (both ebuilds
and installed ones) instantly started supporting multilib.
This has a few important implications:
1. when trying to install (upgrade) a multilib package, portage may not
upgrade its dependencies to proper multilib versions, therefore
triggering seemingly random failures or limitations,
2. when trying to stabilize a multilib package without stabilizing
multilib versions of its dependencies, repoman may not complain if
there is at least a single EAPI<5 version available,
3. when such a stabilization happens, the upgrade of this package on
stable arch will cause emerge to downgrade the dependency to EAPI<5
version.
While we were roughly aware of the first implication, we were not of
the latter two. This was specifically brought to us by _AxS_ who
keyworded multilib ffmpeg on stable amd64 (without keywording libsdl)
and noticed that this causes portage to downgrade EAPI=5, non-multilib
libsdl-1.2.15-r4 to EAPI=2 libsdl-1.2.15-r2. A similar issue was also
reported on the Forums [5].
We've discussed this with the PMS team and the Portage team, and it
seems that the only safe and portable way of fixing this is through
using proper >= dependencies. More specifically, making sure that all
dependencies on multilib packages require proper versions so that no
EAPI<5, non-multilib package can satisfy it.
We've decided to satisfy this requirement through using dependencies of
the following form:
>=dev-foo/bar-${MIN_PV}[${MULTILIB_USEDEP}]
where ${MIN_PV} corresponds to a version that is at least the lower of
the following two versions:
a) the lowest version of the package that is EAPI=5 and
is not followed by any EAPI<5 ebuild,
b) the lowest version of the package that supports multilib and is not
followed by any non-multilib ebuild.
While a) may seem unnecessary considering b), it decreases the number
of stabilizations necessary. It also makes it possible to backport
the multilib support without adjusting deps. However, it relies on
developers not committing new EAPI<5 ebuilds following EAPI=5 ebuilds,
or new non-multilib ebuilds following multilib ebuilds.
Since adding proper versions for every single dependency would be
tedious, we provide multilib-dep-fixor [6] to help with that. The usage
is pretty simple:
multilib-dep-fixor *.ebuild
and it tries to rewrite all multilib dependencies into proper >=-deps.
However, it has a few limitations. More specifically:
a) it doesn't handle variable substitution (${PV}, ${SLOT} in versions),
b) it doesn't handle <, <=, = and ~ deps,
c) it doesn't handle the cases when the newest ebuild is non-multilib
and EAPI<5 (for example, rotting masked or live ebuild),
d) it doesn't look into the past and takes the safe side. So if
the oldest available ebuild is EAPI=5 or multilib, it adds >= dep
on that version.
I've committed dependency corrections to most of the gentoo-x86 ebuilds
today. Please note that this may cause some of the open stablereqs to
require new packages being stabilized. The issues related to the semi-
automatic fixing can be reported in bug #513718 [7].
I will be committing the remaining dependency corrections as soon as it
becomes possible -- that is, as soon as required dependencies are
stabilized. The stable packages with missing stable dependencies are
tracked in bug #507148 [8].
Thank you for your cooperation. If you have any questions, please do
not hesitate to ask.
[1]:https://wiki.gentoo.org/wiki/Project:Multilib/RoadMap
[2]:https://wiki.gentoo.org/wiki/Multilib_porting_status#Emul-.2A_Package_Porting_Overview
[3]:https://wiki.gentoo.org/wiki/Multilib_porting_status#Dependency_update_status
[4]:https://bugs.gentoo.org/show_bug.cgi?id=488776
[5]:https://forums.gentoo.org/viewtopic-t-993228-highlight-.html
[6]:https://bitbucket.org/mgorny/multilib-dep-fixor/src
[7]:https://bugs.gentoo.org/show_bug.cgi?id=513718
[8]:https://bugs.gentoo.org/show_bug.cgi?id=507148
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
