On Fri, 18 Jan 2019 21:13:34 +0100 Michał Górny <[email protected]> wrote:
> 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. I have noticed this and more generally that slot operators are poorly understood, which is frustrating. I was initially inclined to say that I think the model still fits and we should educate devs better but... > 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. I can't say I've ever seen this happen but I don't speak to many users. I'll buy it. > 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. This I certainly agree with. It's so bad that it puts you off adding it at all. > 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? I'm on board as I have to deal with this a lot in games and I think there were one or two more on my list to add. The only downside is that packages requiring what is currently the latest version would need to be updated later, though I guess you could use || instead. Take libpng, for example: || ( =media-libs/libpng-1.6* media-libs/libpng-bin-compat:1.6 ) Or perhaps? || ( media-libs/libpng:0/16 media-libs/libpng-bin-compat:1.6 ) The security team may want to comment on how this will affect GLSAs, especially as these old versions are frequently vulnerable. -- James Le Cuirot (chewi) Gentoo Linux Developer
pgpjPGqXJumhI.pgp
Description: OpenPGP digital signature
