1 |
On Fri, 18 Jan 2019 21:13:34 +0100 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> Hello, |
5 |
> |
6 |
> Since I've been working on the early gx86-multilib, we've been using |
7 |
> 'binary-only SLOTs' to support providing old versions of libraries for |
8 |
> prebuilt software. I think this was a bad idea, and I'd like to suggest |
9 |
> replacing it with something cleaner, for the reasons outlined below. |
10 |
> |
11 |
> |
12 |
> Current state |
13 |
> ============= |
14 |
> |
15 |
> Let's take dev-libs/openssl as an example. This package has three SLOTs |
16 |
> right now: |
17 |
> |
18 |
> 0.9.8: 0.9.8z_p8-r1 |
19 |
> 1.0.0: 1.0.2q-r200 |
20 |
> 0 : 1.0.2q 1.1.0j 1.1.1a 1.1.1a-r1 |
21 |
> |
22 |
> The real package is provided as slot :0, that includes all libraries, |
23 |
> headers and executables. Slots 0.9.8 and 1.0.0 only install .so.N* |
24 |
> libraries that can be used to satisfy dependencies of prebuilt packages. |
25 |
> |
26 |
> |
27 |
> Problems with the current state |
28 |
> =============================== |
29 |
> |
30 |
> Firstly, it is confusing to developers. Let's analyze the dependencies |
31 |
> on dev-libs/openssl. A quick grep reveals seven patterns. They are |
32 |
> listed below, along with occurrence counts and percentages: |
33 |
> |
34 |
> dev-libs/openssl 278 7.8% } |
35 |
> dev-libs/openssl:* 49 1.4% } 14.2% |
36 |
> dev-libs/openssl:= 178 5.0% } |
37 |
> dev-libs/openssl:0 660 18.6% |
38 |
> dev-libs/openssl:0= 2381 67.0% |
39 |
> dev-libs/openssl:0/0 4 0.1% |
40 |
> dev-libs/openssl:0/1.1 2 0.1% |
41 |
> |
42 |
> (note that those are rough measures, not guaranteed to be precise) |
43 |
> |
44 |
> So apparently 14.2% of dependencies allow any slot of OpenSSL which is |
45 |
> most likely wrong, and 1.4% explicitly claim that's what the package |
46 |
> wants. This could be valid only if e.g. the package supported multiple |
47 |
> ABIs of OpenSSL libraries and used dlopen() with a few possible SONAMEs |
48 |
> which I honestly doubt any of those packages is doing. |
49 |
> |
50 |
> In other words, 14.2% of dependencies on OpenSSL are plain wrong, |
51 |
> and 6.4% are wrong in a way that isn't going to be reported by repoman. |
52 |
> 1.4% of cases are using ':*' which probably indicates the developer |
53 |
> decided to silence repoman without understanding how slot operators work |
54 |
> which is a horrible thing from QA perspective. |
55 |
> |
56 |
> We also have a few cases that require specific OpenSSL subslot (e.g. |
57 |
> forcing old version into :0 slot) but *none* actually using the binary |
58 |
> compatibility slots. |
59 |
|
60 |
I have noticed this and more generally that slot operators are poorly |
61 |
understood, which is frustrating. I was initially inclined to say that |
62 |
I think the model still fits and we should educate devs better but... |
63 |
|
64 |
> Secondly, it is confusing to users. If we remove old versions and only |
65 |
> keep binary compatibility slots, users can be easily tricked into |
66 |
> installing them and being surprised it's not a complete package. If we |
67 |
> keep old versions, we end up having different revisions of the same |
68 |
> version in different slots which is also easily confused. |
69 |
|
70 |
I can't say I've ever seen this happen but I don't speak to many users. |
71 |
I'll buy it. |
72 |
|
73 |
> Thirdly, it is cumbersome to introduce. If we are to introduce a binary |
74 |
> compatibility slot for a package that didn't have it, we need to update |
75 |
> all reverse dependencies. This usually means researching whether we |
76 |
> should use ':0' or ':0=', and if we get this wrong, we just silence |
77 |
> repoman warning about missing slot-op. |
78 |
|
79 |
This I certainly agree with. It's so bad that it puts you off adding it |
80 |
at all. |
81 |
|
82 |
> All of this considered, I can't think of a single real benefit of using |
83 |
> slots for this purpose. They work but there's nothing really special |
84 |
> about them. |
85 |
> |
86 |
> |
87 |
> Suggested replacement |
88 |
> ===================== |
89 |
> |
90 |
> My suggestion is to move binary compatibility slots into separate |
91 |
> packages. For example, dev-libs/openssl would be split into: |
92 |
> |
93 |
> dev-libs/openssl -- containing the actual package |
94 |
> |
95 |
> dev-libs/openssl-bin-compat -- containing binary compatibility slots |
96 |
> |
97 |
> In this case, all dependencies on dev-libs/openssl would become correct |
98 |
> (or semi-correct, wrt missing := dep) again. Since packages are co- |
99 |
> installable the same way slots are, there is no loss there. Since |
100 |
> nothing depends on binary compatibility slots, we do not even need to |
101 |
> update anything (but if we had, the update cost would be minimal both to |
102 |
> developers and to users). |
103 |
> |
104 |
> |
105 |
> What do you think? |
106 |
|
107 |
I'm on board as I have to deal with this a lot in games and I think |
108 |
there were one or two more on my list to add. |
109 |
|
110 |
The only downside is that packages requiring what is currently the |
111 |
latest version would need to be updated later, though I guess you could |
112 |
use || instead. Take libpng, for example: |
113 |
|
114 |
|| ( =media-libs/libpng-1.6* media-libs/libpng-bin-compat:1.6 ) |
115 |
|
116 |
Or perhaps? |
117 |
|
118 |
|| ( media-libs/libpng:0/16 media-libs/libpng-bin-compat:1.6 ) |
119 |
|
120 |
The security team may want to comment on how this will affect GLSAs, |
121 |
especially as these old versions are frequently vulnerable. |
122 |
|
123 |
-- |
124 |
James Le Cuirot (chewi) |
125 |
Gentoo Linux Developer |