Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Multilib dependencies need to have >= on least version having EAPI=5 or multilib support
Date: Wed, 18 Jun 2014 22:13:30
Message-Id: 20140619001312.7fe623ca@pomiot.lan
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies