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

[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?

-- 
Best regards,
Michał Górny