Re: [E-devel] Debian Sid (Unstable) packagings for efl-1.23.3 and E23 e17_0.23.1
On Tue, 18 Feb 2020 23:08:46 -0800 Ross Vandegrift said: > On Tue, Feb 18, 2020 at 12:02:45AM +, Carsten Haitzler wrote: > > On Mon, 17 Feb 2020 15:30:04 -0800 Ross Vandegrift said: > > > > > On Mon, Feb 17, 2020 at 09:41:48AM +, Carsten Haitzler wrote: > > > > On Sun, 16 Feb 2020 22:37:40 -0800 Ross Vandegrift > > > > 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/e* ... 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,
Re: [E-devel] Debian Sid (Unstable) packagings for efl-1.23.3 and E23 e17_0.23.1
On Tue, Feb 18, 2020 at 12:02:45AM +, Carsten Haitzler wrote: > On Mon, 17 Feb 2020 15:30:04 -0800 Ross Vandegrift said: > > > On Mon, Feb 17, 2020 at 09:41:48AM +, Carsten Haitzler wrote: > > > On Sun, 16 Feb 2020 22:37:40 -0800 Ross Vandegrift > > > 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
Re: [E-devel] Debian Sid (Unstable) packagings for efl-1.23.3 and E23 e17_0.23.1
On Mon, 17 Feb 2020 15:30:04 -0800 Ross Vandegrift said: > On Mon, Feb 17, 2020 at 09:41:48AM +, Carsten Haitzler wrote: > > On Sun, 16 Feb 2020 22:37:40 -0800 Ross Vandegrift 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... :) > > the cmake files missing will break some things like ecrire from > > compiling as they just use the native cmake checks (reminds me -0 i should > > just port it to meson :)). > > The only missing cmake files are for the cxx bindings - which we don't > currently build. I doubt anyone is missing them without the libs :) > > The rest of the cmake files are in libefl-all-dev. oh they went there. then ok :) > > i noticed elementary_perf itself is missing too. so > > is elementary_test - entirely. no package seems to include it (makes our > > lives hard when we ask people to run it and it doesn't exist). i've looked > > at https://packages.debian.org/search?searchon=names=elementary > > and can't find it listed in the files for anything there. but oddly lots of > > data files that are only needed by it in libelementary-data - so shipping > > lots of useless data there not used by anything because the thing that > > needs the data files isn't packaged anywhere i can find. > > Yea, that's not a great situation. I didn't realize that these could > be useful to non EFL devs. I'll add them for the next release. :) it's one of those test things "run this - does it work?" and then we go from there... like someone says "terminology doesnt display" and i'm going ot ask to see if other efl apps display or not and elementary_test will be a good goto-test thing that also can exercise windows with alpha and so on ... :) > > for enlightenment, i don't see the point of splitting it up as it stands > > into enlightenment and enlightenment-data. it just makes life more > > complicated. > > It's an implementation detail - enlightenment always depends on the same > version of enlightenment-data. apt will ensure they are > installed/upgraded together. Users shouldn't ever have to care. > > The purpose is to save bandwidth & storage for mirror operators. -data > packages are arch independent to avoid making multiple copies per arch. hmm ok. that makes sense then. but just expect they will upgrade along with e so it doesnt avoid an extra download for users. > > 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? > > my point here is... if you do not package everything together as one unit > > and split it out, be very careful how you split and if you leave things out > > then it's quite likely you may have broken some functionality. if you > > split, then it may also break things unless the user remembers to install > > extra packages they may not realize they
Re: [E-devel] Debian Sid (Unstable) packagings for efl-1.23.3 and E23 e17_0.23.1
On Mon, Feb 17, 2020 at 09:41:48AM +, Carsten Haitzler wrote: > On Sun, 16 Feb 2020 22:37:40 -0800 Ross Vandegrift 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. > the cmake files missing will break some things like ecrire from > compiling as they just use the native cmake checks (reminds me -0 i should > just port it to meson :)). The only missing cmake files are for the cxx bindings - which we don't currently build. I doubt anyone is missing them without the libs :) The rest of the cmake files are in libefl-all-dev. > i noticed elementary_perf itself is missing too. so > is elementary_test - entirely. no package seems to include it (makes our lives > hard when we ask people to run it and it doesn't exist). i've looked at > https://packages.debian.org/search?searchon=names=elementary and > can't > find it listed in the files for anything there. but oddly lots of data files > that are only needed by it in libelementary-data - so shipping lots of useless > data there not used by anything because the thing that needs the data files > isn't packaged anywhere i can find. Yea, that's not a great situation. I didn't realize that these could be useful to non EFL devs. I'll add them for the next release. > for enlightenment, i don't see the point of splitting it up as it stands into > enlightenment and enlightenment-data. it just makes life more complicated. It's an implementation detail - enlightenment always depends on the same version of enlightenment-data. apt will ensure they are installed/upgraded together. Users shouldn't ever have to care. The purpose is to save bandwidth & storage for mirror operators. -data packages are arch independent to avoid making multiple copies per arch. > 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. > my point here is... if you do not package everything together as one unit and > split it out, be very careful how you split and if you leave things out then > it's quite likely you may have broken some functionality. if you split, then > it > may also break things unless the user remembers to install extra packages they > may not realize they need. in the end what happens is people turn up with odd > problems upstream and we go "WTF?" since don't realize the packages may have > broken that in subtle ways. IMO these would be packaging bugs - users should be able to ignore the multiple packages. The intended user experiences are like this: - for an end user: install an EFL app (enlightenment, terminology, etc) and apt automatically installs all of the required stuff. - some packages are merely recommended (eg. terminology recommends libelementary-bin for elementary_config.) By default, apt treats these as dependencies. Users that change that know to expect different behavior. - for a developer: install libefl-all-dev and apt will automatically install all libs, headers, and build dependencies. It pretty much works. There have been a few rough cases (had to make all rendering engines mandatory - apt wasn't smart enough to support optional rendering backends while still getting X11 installed by default in all cases.) But all of the issues that I know of have been fixed. As far as I know of, these were all reported to me as Debian bugs. If anyone complained
Re: [E-devel] Debian Sid (Unstable) packagings for efl-1.23.3 and E23 e17_0.23.1
On Sun, 16 Feb 2020 22:37:40 -0800 Ross Vandegrift said: > Hi Jose, > > 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). the cmake files missing will break some things like ecrire from compiling as they just use the native cmake checks (reminds me -0 i should just port it to meson :)). i noticed elementary_perf itself is missing too. so is elementary_test - entirely. no package seems to include it (makes our lives hard when we ask people to run it and it doesn't exist). i've looked at https://packages.debian.org/search?searchon=names=elementary and can't find it listed in the files for anything there. but oddly lots of data files that are only needed by it in libelementary-data - so shipping lots of useless data there not used by anything because the thing that needs the data files isn't packaged anywhere i can find. for enlightenment, i don't see the point of splitting it up as it stands into enlightenment and enlightenment-data. it just makes life more complicated. data and enlightenment are intrinsically linked. especially the config profiles, imc, test images (to test efl support for those formats it not broken), etc. - as config revs versions alongside e releases and enlightenment cannot function without its data. the .mo files are also tied to the binaries as they provide strings for that binary and these change. the data will necessarily upgrade alongside e and so splitting them makes no sense as they always upgrade together as a unit and one depends directly on the other explicitly. i'd advise just having the enlightenment package provide enlightenment-data in future as a transition for a while and have a single package. i'd also suggest the same simplification of the efl pkgs like e - merge them all into a single libefl (transition by having one of the libe* packages start providing this) then merge it all into this (split it between libefl and libefl-dev) and have these provide all of the "legacy packages" appropriately. for tools like elementary_test, elementary_perf, edje_player, ecore_evas_convert, eet, etc. - these are "handy tools" to perhaps libefl-tools and then there are specific developer tools like edje_cc, embryo_cc etc. which are probably either part of libefl-dev or libefl-devtools. there re key tools like elementary_config without which you can't (easily) alter the config for elementary so they probably should just be part of libefl. some binaries are tied directly to the functionality of efl like efreetd, ethumbd, ethumbd_client and also eina_btlog (the binaries in PREFIX/lib/e/... are absolutely tied always to efl and should never be split out from their respective libs). my point here is... if you do not package everything together as one unit and split it out, be very careful how you split and if you leave things out then it's quite likely you may have broken some functionality. if you split, then it may also break things unless the user remembers to install extra packages they may not realize they need. in the end what happens is people turn up with odd problems upstream and we go "WTF?" since don't realize the packages may have broken that in subtle ways. if you want to have things split up - please talk to us. when we add new things that get installed, talk to us. :) sure - some things might be better off not in PREFIX/bin - and maybe in our libdirs (ethumbd* efreetd etc.) ... in hindsight we maybe should have explicitly namespaced our tools between key dev tools, user visible tools and test/debug tools, but we didn't and changing their names is not going to make users quite unhappy. :(. even the kind of namespacing depends on the kind of splitting going on so i'm not sure it's even universally doable (e.g. it's just normal/core vs dev/devel or also tools, usertools, devtools and other categories) :) :) -- - Codito, ergo sum - "I code,
Re: [E-devel] Debian Sid (Unstable) packagings for efl-1.23.3 and E23 e17_0.23.1
Hi Jose, 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. Ross ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
