Hello, Since I've been working on the early gx86-multilib, we've been using 'binary-only SLOTs' to support providing old versions of libraries for prebuilt software. I think this was a bad idea, and I'd like to suggest replacing it with something cleaner, for the reasons outlined below.
Current state ============= Let's take dev-libs/openssl as an example. This package has three SLOTs right now: 0.9.8: 0.9.8z_p8-r1 1.0.0: 1.0.2q-r200 0 : 1.0.2q 1.1.0j 1.1.1a 1.1.1a-r1 The real package is provided as slot :0, that includes all libraries, headers and executables. Slots 0.9.8 and 1.0.0 only install .so.N* libraries that can be used to satisfy dependencies of prebuilt packages. Problems with the current state =============================== Firstly, it is confusing to developers. Let's analyze the dependencies on dev-libs/openssl. A quick grep reveals seven patterns. They are listed below, along with occurrence counts and percentages: dev-libs/openssl 278 7.8% } dev-libs/openssl:* 49 1.4% } 14.2% dev-libs/openssl:= 178 5.0% } dev-libs/openssl:0 660 18.6% dev-libs/openssl:0= 2381 67.0% dev-libs/openssl:0/0 4 0.1% dev-libs/openssl:0/1.1 2 0.1% (note that those are rough measures, not guaranteed to be precise) So apparently 14.2% of dependencies allow any slot of OpenSSL which is most likely wrong, and 1.4% explicitly claim that's what the package wants. This could be valid only if e.g. the package supported multiple ABIs of OpenSSL libraries and used dlopen() with a few possible SONAMEs which I honestly doubt any of those packages is doing. In other words, 14.2% of dependencies on OpenSSL are plain wrong, and 6.4% are wrong in a way that isn't going to be reported by repoman. 1.4% of cases are using ':*' which probably indicates the developer decided to silence repoman without understanding how slot operators work which is a horrible thing from QA perspective. We also have a few cases that require specific OpenSSL subslot (e.g. forcing old version into :0 slot) but *none* actually using the binary compatibility slots. Secondly, it is confusing to users. If we remove old versions and only keep binary compatibility slots, users can be easily tricked into installing them and being surprised it's not a complete package. If we keep old versions, we end up having different revisions of the same version in different slots which is also easily confused. Thirdly, it is cumbersome to introduce. If we are to introduce a binary compatibility slot for a package that didn't have it, we need to update all reverse dependencies. This usually means researching whether we should use ':0' or ':0=', and if we get this wrong, we just silence repoman warning about missing slot-op. All of this considered, I can't think of a single real benefit of using slots for this purpose. They work but there's nothing really special about them. Suggested replacement ===================== My suggestion is to move binary compatibility slots into separate packages. For example, dev-libs/openssl would be split into: dev-libs/openssl -- containing the actual package dev-libs/openssl-bin-compat -- containing binary compatibility slots In this case, all dependencies on dev-libs/openssl would become correct (or semi-correct, wrt missing := dep) again. Since packages are co- installable the same way slots are, there is no loss there. Since nothing depends on binary compatibility slots, we do not even need to update anything (but if we had, the update cost would be minimal both to developers and to users). What do you think? -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
