Bundling EFL library packages

[Andreas Metzler]

On 2020-02-20 Ross Vandegrift <rvandegrift at debian.org> wrote:
> Hello,

> I'm considering bundling all of the EFL shared objects into a single
> package.  I thought this would not be permitted by policy.  But after
> a discussion with upstream, I reviewed the policy and realized I was
> wrong - it is not so strict.

> An initial plan:
> - libefl1: all of the shared libs & modules
[...]

Hello Ross,

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

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.

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

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'