Re: [gentoo-dev] [RFC] Replacing binary-only SLOTs with separate packages

[Mart Raudsepp]

Ü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