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? > > > 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. 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. - 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. Ross _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
