Bundling EFL library packages

[Ross Vandegrift]

Hello,

On Wed, Feb 19, 2020 at 10:44:54PM -0800, Ross Vandegrift wrote:
> 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
> - libefl-data: arch-indep user files
> - libefl-bin: user binaries
> - libefl-dev: arch-indep developer files
> - libefl-dev-bin: developer binaries
> - libefl-doc: api docs
> Existing packages will become transitional as appropriate.

I've worked through this, and I'm not that fond of the result.  It turns out
that not all of the dependency cycles can be eliminated - bundling creates a
new ineliminable cycle:

ethumb has a client and server.  The client has a shared lib and runtime bin.
Currently those are shipped in libethumb-client1 and libethumb-client-bin.
libethumb-client-bin depends on libethumb-client1 since it is linked to it.
But to avoid the cycle, there's no dependency in the other direction.  Instead,
libethumb-client1.symbols adds a dependency on libethumb-client-bin to
consumers.

But libelementary.so.1 is linked to libethumb_client.so.1.  Once bundled,
elementary will be in libefl1.  And of course ethumb uses efl, so it depends on
libefl1 - we get: libefl1 <-> libethumb-client-bin.

To workaround, we'd need to keep ethumb split out so consumers can include both
dependencies on libethumb-client1 and libethumb-client-bin.  But we'd also need
to keep libelementary1 separate to avoid a cycle with the bundled libefl1.  I
don't see a path from libelementary1 -> libethumb-client1 right now, but I
haven't actually tested this.

That would leave us in a middle-ground where some of efl must be kept separate,
some bundled.  But that's the current state of things.  So this seems like lots
of churn to end up with just a reshuffle of what's bundled.

Some comments on the other discussion points follow.


> Here are some benefits:
[snip]
> - Ensuring that all components are the same verson takes a lot of Breaks.  This
>   would become very simple.

It's not really simpler - I wasn't thinking about everything needed to get the
transitional packages right.  A better idea is to automate checking for the
relationships so the complexity isn't as hard to manage.

> - Upstream experiments with new libraries & functionality.  This avoids new
>   binary packages every time a new library is introduced.
> 
> - Splitting the arch-indep files can be done more completely without adding
>   lots of small binary packages.

These advantages do pan out - with the proviso that new functionality might
require reintroducing binary packages to break future cycles.

> - Cleaning up historical baggae from the pre-merge EFL <1.8 era back in 2013.

Same here.  It's nice to be able to clean this up, except that a large amount
of new baggage is introduced.

> There are some costs:
> - installed size footprint will increase slightly (only ~1MB for systems with
>   enlightenment installed).
> 
> - a large symbols file will be harder to maintain.  Maybe there are tricks for
>   splitting it up though.

I used per-so symbols files that were combined in execute_before_dh_makeshlibs.
This worked pretty well.

> I examined the lib* packages on my system.  There are a few that bundle many
> libraries, so it seems not so uncommon.  But I'm also going to ask for feedback
> on mentors before implementing.
> 
> 
> Thoughts?

For now, I don't think I'm going to bundle everything.  That could change if
upstream's efl-one work completes, or if it eventually makes sens to live with
cycles.  But since it wasn't a clear win, I don't feel compelled to do this
now.

Ross