Re: [E-devel] Debian Sid (Unstable) packagings for efl-1.23.3 and E23 e17_0.23.1

[Carsten H. <ra...@ra...>]

On Tue, 18 Feb 2020 23:08:46 -0800 Ross Vandegrift <ro...@ka...> said:

> On Tue, Feb 18, 2020 at 12:02:45AM +0000, Carsten Haitzler wrote:
> > On Mon, 17 Feb 2020 15:30:04 -0800 Ross Vandegrift <ro...@ka...> said:
> > 
> > > On Mon, Feb 17, 2020 at 09:41:48AM +0000, Carsten Haitzler wrote:
> > > > On Sun, 16 Feb 2020 22:37:40 -0800 Ross Vandegrift <ro...@ka...>
> > > > said:
> > > > > On Sat, Feb 15, 2020 at 09:37:59PM -0800, Jose R R wrote:
> > > > > > For EFL, I replaced libcurl4-gnutls-dev with libcurl4-openssl-dev to
> > > > > > be consistent with most of what I build --including reiser4 VMs for
> > > > > > Google cloud env..
> > > > > > The build finished but the logs showed *many* dh-missing files the
> > > > > > Debian packaging had no *.installation instructions for.
> > > > > 
> > > > > These are left out intentionally so dh_missing is set to just warn.
> > > > > Unfortunately, d/not-installed does not support wildcards yet - so
> > > > > there's no (easy) way to suppress those messages.
> > > > > 
> > > > > > For E23.1 the build failed due to the copious quantity of dh-missing
> > > > > > files.
> > > > > 
> > > > > Unlike efl, enlightenemnt's packaging is set to fail on any missing
> > > > > files. (compare their d/rules and read the manpage for dh_missing).
> > > > > There aren't failures due to missing files on my local builds or the
> > > > > official buildds.
> > > > > 
> > > > > I don't know why your build failed.  But the patch is not correct.
> > > > > usr/share/enlightenment/data is already in the install file, so it
> > > > > adds nothing new.
> > > > 
> > > > actually a lot of those files being left out would be a bug. the missing
> > > > checkme files for one are a going to break part of efl's behaviour
> > > > (relocation).
> > > 
> > > This is sort of on purpose - given Debian's requirements, it seems
> > > unlikely for those to work relocated.  I thought it'd be better for
> > > those folks to build themselves.  But maybe I'm wrong - afaik, no one
> > > has tried or asked for this feature so it's just a gut feeling.
> > 
> > if you included them someone can just tar up just the efl files from /usr
> > and drop them (all relative paths the same) in /opt/pants and efl will
> > work. or it should. it saves them having to compile again for a new prefix
> > and can just use the packaged files as-is... this actually allows some
> > packaging systems like rpm's relocatable packages "just work" with efl. :)
> > just saying that you force people into recompiling by making an effort to
> > remove files... :)
> 
> Fair enough - I think the effort to support that is probably low.  But I'm
> curious- why would someone want to do that?

because efl is large, broken into many modules loaded at runtime, some
daemons/tools and even worse.... data files like default theme, default cfg
profiles etc. necessary for elementary to work... what do you do  about
statically linking efl into an app? other toolkits do this just they are not
like efl above. it's essentially impossible to statically compile  efl into a
binary even if the libexxx.sl files can be.  modules can be also configured to
be static ... but its all pointless with things like efreetd,  ethumbd and
efl.net's out of process pacrunner tool for proxy config files. so instead efl
is relocatable. just  ship your proposed app with efl in its dir tree, keeping
prefix for efl. so maybe:

appdir/launcher <- sets LD_LIBRARY_PATH based on where appdir is
appdir/mybinary <- launched by the above once setting up env dirs
appdir/efl
appdir/efl/lib/libexxx.so*
appdir/efl/lib/elibdirs*
appdir/efl/bin/etools*
appdir/efl/share/elementary/*
appdir/efl/share/exxxx*
...

so it's a little work for launcher to figure this out. it's easy with
dlsym+dlinfo. just query the path src of a symbol in your own binary like
main(). so it solves the static linking issue. even better it allows the end
user to upgrade the efl used in the app by dropping in a new one in place of
the one there, or use the host system efl and rm -rf the shipped efl. doesn't
requite dev pkgs to ship .a files to allow static linking saving lots of
space...

it's a massively better solution to static linking.

> > > > i'd also suggest the same simplification of the efl pkgs like e - merge
> > > > them all into a single libefl
> > > 
> > > This wouldn't meet Debian's policy for packaging shared libraries - so
> > > the result couldn't be included in Debian.  That's my goal, so I'm stuck
> > > with the complication.
> > 
> > you can't merge? or you cant include binaries?
> 
> Strictly speaking, Debian policy requires both:
> 
> - Shared objects should be shipped in individual packges to minimize
> disruption due to incompatible versions.  e.g., if libfoo1 contains libfoo.so.
> 1 AND libbar.so.1, and libbar bumps soname due to an abi/api break, then
> packages that depend on libfoo1 for libbar1  will break.  Splitting them up
> allows libbar.so.1 to remain installed for old programs.  This isn't such a
> concern for EFL's components, since they are required to be the same version
> anyhow.

moot for efl. in fact you cant mix and match. new efl lib of any name will
assume same version of its deps. that's how we do it. we will not allow mix and
match and do not even have checks.

>   BUT - looking back at policy, it's not worded as a strict requirement.  I
>   checked some shared lib packages on my laptop.  A few that bundle libs
> appear to have no reason beyond convenience.  So maybe I'll poke/ask around
> more and revisit this.

it'll not only be easier for you, but it'll reflect upstream development style,
policies and assumptions. :)

> - Binaries can't ship in shared lib packages to support installing multiple
>   versions of the same library.  In Debian, shared lib packages and all files
>   in them names must include the soname.  So I can install packages that
> depend on libfoo1 and libfoo2 simultaneously.  But if libfoo1 and libfoo2
> install different /usr/bin/foo, then the packages must conflict and cannot be
> coinstalled.
> 
>   The EFL packages don't conform to this perfectly - the eina package has had
>   some other stuff added to avoid needing even more packages for a small
> number of files.  But technically, I should be cleaning that up over time.

if we do a major version jump, we'll bump all our include dir names and
versions, our dirs with binary utils and likely binary names too. i'll be an
opportunity for  lot of cleanup of many years of dev. we're aware that an efl2
needs to be parallel installable with efl 1.x so we should take care of this
for you anyway. if we make a mistake, before an efl2 goes out for release, test
and let us know so we fix it. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ra...@ra...