Ühel kenal päeval, R, 18.01.2019 kell 21:13, kirjutas Michał Górny: > 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?
I can only find bikeshed painting for the naming of the legacy packages, so I guess sounds good. Though that historical digging about why we moved away from it may be useful, if just to find that it was just a "SLOTs are cool, lets use them" case, to strengthen the argument to move back to separate package again. Mart
signature.asc
Description: This is a digitally signed message part
