On Tue, 18 Feb 2020 23:08:46 -0800 Ross Vandegrift <r...@kallisti.us> 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 <r...@kallisti.us> 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 <r...@kallisti.us> > > > > 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 - ras...@rasterman.com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
