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

[Michał Górny]

On Sat, 2019-01-19 at 17:37 +0300, Andrew Savchenko wrote:
> 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.

You haven't brought a single argument as to how slots are better than
compat packages.  In fact, it's not even clear if you're talking about
the same use of slots that I am.

> 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,

I don't see how this would change the effective number of ebuilds.  You
can't produce two slots out of a single ebuild, so you always have to
duplicate them.

>  ${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.

Are you saying that there are 'lots' of binary compatibility slots being
currently used right now?  Could you support this claim with actual
numbers or examples?

> 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.

I don't see how binary compatibility slots are even relevant to
sysadmins.  Their only purpose is to satisfy dependencies of other
packages, so sysadmin should never have to care about them.

> Assumption that :* is always wrong is invalid, since there are
> valid cases: there are apps supporting various API versions

Binary compatibility slots are used for ABI incompatibility, not any API
incompatibility.  Also, I have the feeling those 'various API versions'
require headers to build.

>  or
> using tools/data files without any care from where they are coming.

Tools aren't included in binary compatibility slots.  As James already
pointed out in this thread.

-- 
Best regards,
Michał Górny