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. > 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&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. 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 upstream, sorry about that! > when we add new things that get installed, talk to us. :) Thanks for the offer, I'll write if I have a question. The efl side is usually the easier part to figure out. Obviously I made a bad call on elementary_{test,perf}, so there's always possible bugs. Ross _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
