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