Bundling EFL library packages

[Andreas Metzler]

On 2020-02-22 Ross Vandegrift <rvandegrift at debian.org> wrote:
> On Thu, Feb 20, 2020 at 02:48:01PM +0100, Andreas Metzler wrote:
>> I think you forgot to list the biggest downside: soname bumps are hard
>> to handle properly unless the soname is bumped upstream in lockstep over
>> all libraries (probably uselessly, since not all of them will break the
>> ABI at the same time.)

> Yes, this is the biggest risk.  Weird that I didn't mention it.  Here
> are some factors that I think mitigate the risk:

> - Since the merge in 1.8, upstream has said that versions and sonames of
>   components must be kept in sync.  They've stuck with it since then,
>   and it was reiterated at [1].

> - EFL components can use one another's private interfaces.  Hence the
>   requirement that they all be the same version.  So if one lib breaks
>   an interface, all consumers in EFL must be adapted to the new api/abi.
>   This makes it more likely that most components actually do need a
>   soname bump at the same time.

Pretty strong arguments for merging.

>> Consider this:
>> 
>> Status quo (version 1.0) libfoo1, libbar1
>> Proposal: libfooandbar1 (includes libfoo.so.1 and libbar.so.1)
>> 
>> Now with release 2.0 libfoo has an ABI break, bumping the soname to
>> libfoo.so.2.  With a regular setup you simply change the package name to
>> match the soname
>> libfoo2, libbar1
>> and upgrades work without any special handholding since libfoo2 and
>> libfoo1 are co-installable. With a bundled package things get
>> complicated, starting with the question whether you'll change the
>> packagename to libfoo2bar1 or keep the original one. If you
>> kept the original name you would need to come up with some magic to
>> prevent libfoo2bar1 2.0 fullfilling the dependency of the binary
>> package linkedagainstfooandbar on libfooandbar1 (>= 1.0). I currently
>> cannot think of a useful way to do this so I think a new packagename
>> will be needed. libfoo2bar1 would Conflicts or Breaks and
>> Replaces libfooandbar1. This could be done with a virtual package.

> Yea, it get complicated.  I think I understand.

> We could rename libefl1 -> libefl1a -> libefl1b, etc.  Each rename would
> Conflicts & Replace the previous name.

> And one stable release cycle could include multiple library bumps.  Is
> this where the virtual package would come in?  For example, libefl-abi-5
> would retain all of the Conflicts & Replaces on previous releases to
> ensure a stable release containing libefl1a could be upgraded to a
> stable release with libefl1d.

The virtual package would[1] make the Breaks/Conflicts maintenance-free and
keep it short.

Instead of
Package: libefl1

Package: libefl1a
Breaks: libefl1
Replaces: libefl1

Package: libefl1b
Breaks: libefl1, libefl1a
Replaces: libefl1, libefl1a
etc.

you do
Package: libefl1
Provides: efl-lib-bundle
Breaks: efl-lib-bundle
Replaces: efl-lib-bundle

Package: libefl1a
Provides: efl-lib-bundle
Breaks: efl-lib-bundle
Replaces: efl-lib-bundle

Package: libefl1b
Provides: efl-lib-bundle
Breaks: efl-lib-bundle
Replaces: efl-lib-bundle

Regarding Breaks/Conflicts I /think/ [2] the weaker form (Breaks) would
be sufficient and therefore the right thing. We do not need to prevent
simultaneous unpacking of libefl1 and libefl1a.

[1] [2] Untested. And needs a second pair of eyes. :-)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'