On Sun, 16 Feb 2020 22:37:40 -0800 Ross Vandegrift <r...@kallisti.us> 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&keywords=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/exxxx/... 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, 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
