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

[Andrew Savchenko]

On Fri, 18 Jan 2019 21:13:34 +0100 Michał Górny 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.
>
>
> 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 do not like the idea. Slots are very elegant and effective
mechanism and is one of the points where Gentoo outruns other
distributions. Proposed approach with compat packages will
effectively disable slots for most cases.

Also proposed change will create a lot of unneeded technical
difficulties in maintaining packages: there will be double ebuilds
to maintain instead of a single one, ${PN} references will be
broken without additional changes and so far and so on. A lot of
unnecessary rebuilds will happen due slot to package moves.

Aside from development questions for me in a role of sysadmin slots
are much easier and understandable to manage than zoo of *compat*
packages in other distributions.

Assumption that :* is always wrong is invalid, since there are
valid cases: there are apps supporting various API versions or
using tools/data files without any care from where they are coming.

Best regards,
Andrew Savchenko