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... :) > > 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&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. :) 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 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: they would be. the problem is ... they don't get found easily. :( > - 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! until we splut out the x11 vs wl vs... stuff inside libelementary it's kind of moot actually as elm itself will suck in x and.or wl deps on its own so it isnt cleanly isolatable into modules just for one display system or the other (or both). > > 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. No problems. that's why i bring it up now i take a quick look. :) we're happy to work with you and provide information and guidance and discussion. it works both ways too. we get feedback too to roll into the future of efl that's needed or desired. :) -- ------------- 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
