1 |
Hi, developers and users. |
2 |
|
3 |
TLDR: if you do [${MULTILIB_USEDEP}] or [abi_x86_32], always use >= dep |
4 |
on the oldest package version that is EAPI=5 or multilib. In other |
5 |
words, the >= dependency must not match a single non-multilib, EAPI<5 |
6 |
ebuild. And please do not commit new EAPI<5 ebuilds following EAPI=5 |
7 |
ebuilds. |
8 |
|
9 |
Long version: |
10 |
|
11 |
First of all, I'd like to thank all supporters of our little multilib |
12 |
effort. We're getting pretty close to finishing stage 1 of our roadmap |
13 |
[1], with most of important packages being multilib-ready already [2]. |
14 |
Most of our effort right now is focused on fixing 32-bit package |
15 |
dependencies [3]. |
16 |
|
17 |
However, it was lately brought to my attention that the very complex |
18 |
issue regarding portage behavior wrt USE_EXPAND flags and EAPI<5. Since |
19 |
PMS is awfully incomprehensible in this area, I won't get into the fine |
20 |
details. The same issue was discussed wrt Python in bug #446720 [4]. |
21 |
|
22 |
The important part is that a dependency of the following form: |
23 |
|
24 |
dev-foo/bar[abi_x86_64(-),abi_x86_32(-)...] |
25 |
|
26 |
can be satisfied not only by multilib ebuilds. It is also satisfied by |
27 |
EAPI<5 ebuilds that don't have abi_* flags in IUSE if the user has |
28 |
enabled respective abi_* flags globally. In other words, if the user |
29 |
has: |
30 |
|
31 |
ABI_X86="32 64" |
32 |
|
33 |
in his make.conf, portage thinks that all EAPI<5 packages (both ebuilds |
34 |
and installed ones) instantly started supporting multilib. |
35 |
|
36 |
|
37 |
This has a few important implications: |
38 |
|
39 |
1. when trying to install (upgrade) a multilib package, portage may not |
40 |
upgrade its dependencies to proper multilib versions, therefore |
41 |
triggering seemingly random failures or limitations, |
42 |
|
43 |
2. when trying to stabilize a multilib package without stabilizing |
44 |
multilib versions of its dependencies, repoman may not complain if |
45 |
there is at least a single EAPI<5 version available, |
46 |
|
47 |
3. when such a stabilization happens, the upgrade of this package on |
48 |
stable arch will cause emerge to downgrade the dependency to EAPI<5 |
49 |
version. |
50 |
|
51 |
While we were roughly aware of the first implication, we were not of |
52 |
the latter two. This was specifically brought to us by _AxS_ who |
53 |
keyworded multilib ffmpeg on stable amd64 (without keywording libsdl) |
54 |
and noticed that this causes portage to downgrade EAPI=5, non-multilib |
55 |
libsdl-1.2.15-r4 to EAPI=2 libsdl-1.2.15-r2. A similar issue was also |
56 |
reported on the Forums [5]. |
57 |
|
58 |
|
59 |
We've discussed this with the PMS team and the Portage team, and it |
60 |
seems that the only safe and portable way of fixing this is through |
61 |
using proper >= dependencies. More specifically, making sure that all |
62 |
dependencies on multilib packages require proper versions so that no |
63 |
EAPI<5, non-multilib package can satisfy it. |
64 |
|
65 |
We've decided to satisfy this requirement through using dependencies of |
66 |
the following form: |
67 |
|
68 |
>=dev-foo/bar-${MIN_PV}[${MULTILIB_USEDEP}] |
69 |
|
70 |
where ${MIN_PV} corresponds to a version that is at least the lower of |
71 |
the following two versions: |
72 |
|
73 |
a) the lowest version of the package that is EAPI=5 and |
74 |
is not followed by any EAPI<5 ebuild, |
75 |
|
76 |
b) the lowest version of the package that supports multilib and is not |
77 |
followed by any non-multilib ebuild. |
78 |
|
79 |
While a) may seem unnecessary considering b), it decreases the number |
80 |
of stabilizations necessary. It also makes it possible to backport |
81 |
the multilib support without adjusting deps. However, it relies on |
82 |
developers not committing new EAPI<5 ebuilds following EAPI=5 ebuilds, |
83 |
or new non-multilib ebuilds following multilib ebuilds. |
84 |
|
85 |
|
86 |
Since adding proper versions for every single dependency would be |
87 |
tedious, we provide multilib-dep-fixor [6] to help with that. The usage |
88 |
is pretty simple: |
89 |
|
90 |
multilib-dep-fixor *.ebuild |
91 |
|
92 |
and it tries to rewrite all multilib dependencies into proper >=-deps. |
93 |
However, it has a few limitations. More specifically: |
94 |
|
95 |
a) it doesn't handle variable substitution (${PV}, ${SLOT} in versions), |
96 |
|
97 |
b) it doesn't handle <, <=, = and ~ deps, |
98 |
|
99 |
c) it doesn't handle the cases when the newest ebuild is non-multilib |
100 |
and EAPI<5 (for example, rotting masked or live ebuild), |
101 |
|
102 |
d) it doesn't look into the past and takes the safe side. So if |
103 |
the oldest available ebuild is EAPI=5 or multilib, it adds >= dep |
104 |
on that version. |
105 |
|
106 |
|
107 |
I've committed dependency corrections to most of the gentoo-x86 ebuilds |
108 |
today. Please note that this may cause some of the open stablereqs to |
109 |
require new packages being stabilized. The issues related to the semi- |
110 |
automatic fixing can be reported in bug #513718 [7]. |
111 |
|
112 |
I will be committing the remaining dependency corrections as soon as it |
113 |
becomes possible -- that is, as soon as required dependencies are |
114 |
stabilized. The stable packages with missing stable dependencies are |
115 |
tracked in bug #507148 [8]. |
116 |
|
117 |
|
118 |
Thank you for your cooperation. If you have any questions, please do |
119 |
not hesitate to ask. |
120 |
|
121 |
[1]:https://wiki.gentoo.org/wiki/Project:Multilib/RoadMap |
122 |
[2]:https://wiki.gentoo.org/wiki/Multilib_porting_status#Emul-.2A_Package_Porting_Overview |
123 |
[3]:https://wiki.gentoo.org/wiki/Multilib_porting_status#Dependency_update_status |
124 |
[4]:https://bugs.gentoo.org/show_bug.cgi?id=488776 |
125 |
[5]:https://forums.gentoo.org/viewtopic-t-993228-highlight-.html |
126 |
[6]:https://bitbucket.org/mgorny/multilib-dep-fixor/src |
127 |
[7]:https://bugs.gentoo.org/show_bug.cgi?id=513718 |
128 |
[8]:https://bugs.gentoo.org/show_bug.cgi?id=507148 |
129 |
|
130 |
-- |
131 |
Best regards, |
132 |
Michał Górny |