Bundling EFL library packages

[Ross Vandegrift]

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.

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

> I am not shooting down or vetoing your proposal, there are some *great*
> benefits, I just thought an important piece of information was missing.

Thanks!

Ross

[1] - https://sourceforge.net/p/enlightenment/mailman/message/36927764/