On Mon, 23 Jan 2006 15:51:13 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled:
> On Monday, 23 January 2006, at 23:54:16 (+0900), > Carsten Haitzler wrote: > > > yes - it doesnt. funny that there are a few hundred thousand lines > > of code that need work on - a lot of packages like edje when they > > build dont check for certain support. the bug u saw was a matter of > > the code basically not checking all its return values. this kind fo > > stuff happesn when u have a small team and a lot of code. it gets > > fixed over time. i don't think netuering support is the > > answer. adding the modules to edje's.spec is a much safer and better > > solution that removing the ability to have modules for evas at > > all. it's throwing the baby out with the bathwater. > > This is simply not true. > > edje_cc, as it was before you made your return code fixes, was > perfectly capable of compiling .edc files with no JPEG's in them > without the evas JPEG loader module installed. Likewise, PNG-free > .edc's don't need the PNG loader installed. And I'm willing to bet > that .edc's without either JPEG's or PNG's don't need either loader > module. > > So clearly the correct place for the dependencies is in the .edc files > themselves, not the edje_cc compiler or the edje package. So what you > did is just as much the "wrong solution" as what I did. > > Is it reasonable to put module dependencies into .edc files? And how > can packaging systems like RPM be expected to pick up on those? Or > are we saying that the packagers should be entirely responsible for > keeping track of what evas modules might be required by .edc files in > their packages? > > You have to weigh the idealism of having a separate package for each > module with the practical concerns of dependency and other maintenance > headaches, real-world usefulness, etc. > > I gave it a lot of thought, and I can't come up with a single > real-world example of something that would (1) use RPM as a package > manager, (2) use Evas, and (3) not use the JPEG/PNG loaders or the > buffer engine. Can you? believe it or not - redhat is like the #3 most used OS for "embedded" products - yes.. redhat! fedora is #6 most popular - accor4ding to linuxdevices: http://www.linuxdevices.com/articles/AT4036830962.html so yes. i could imagine a TARGET system that doesnt include edje_cc - BUt does inlude JUSt a runtime edje lib for display of gui data (i would also split edje binary usilts off into another package - edje-cc....rpm). a developer may want supprot - but the target user devices may not. i can DEFINITELY see room for then even not needing the buffer engine nor an x engine (as it may run in the framebuffer directly) etc. etc. etc. > > as i said - this is not the right solution. it doesnt make sense > > when the DEPENDENCIEs of edje can have these moduels added and thus > > explicitly state what features it requires as a base minimum. i > > believe i mentioned this to you on irc when i was making a modular > > .spec - if software needs certain features it can require the > > particular modules. > > Adding dependencies to .spec files is all well and good, but it's a > manual process that has to be maintained. Furthermore, as I > mentioned, edje isn't the right place for those dependencies. The > right place is in the .edc files. and now the fiels will not just fail to build - but dump meaningful errors to let you know you may need more modules. no packages shouldnt know of the deps of a .edc - but then packages dont know of the deps of a source .tar.gz either - do they? thats "out of your hands". > > > You can also look at it this way: I've saved them an immense amount > > > of time hunting down problems they don't understand by including the > > > features that ALMOST ALL PACKAGES which use evas require. > > > > but not ALL. > > Let's hear some counter-examples. And stick to stuff that uses RPM > please, as these are spec files only. I didn't change anything about > the evas build. see above. > > i mean - feel free to make packages as such. my recommendation will > > be to not use them. > > Be sure you explain why when you make that recommendation. I'm > betting anyone who wants to exclude support for those things I merged > in will have to alter the spec file anyway to remove the other build > requirements they don't need. Like X11 (XFree86-devel via eet-devel) > and libjpeg! when BUILDING packages - sure, but not when installing already built packages. i'm talking about installing pre-built packages. if you can build a package - u can alter it. the point is to minimise the need to ever build custom packages. > > and we will see a history as with imlib2 - imlib2 needs x11 because > > itys not modular, but CAN be built withotu x support - suddenyl > > everyone thinks imlib2 NEEDS x and a lot of peoepl who want to use > > it for web sites think they need x instaleld for it then decide not > > to. evas can be used without x - or without png support. the > > packages now basically neuter that ability. > > That "ability" is brand spanking new and still needs to be ironed > out. The simple fact is that the packages which currently exist and > use evas are NOT YET READY to have evas capabilities ripped out from > underneath them. Once we iron this whole thing out, we can revisit > the situation. But for now it's simply not practical to rip all that > stuff out. Too much breakage. > > BTW, I looked for you last night, but you weren't on IRC, so I had to > go ahead and take action. All of the following failed to build with > the new evas spec: > > e_modules-calendar > e_modules-flame > e_modules-mount > e_modules-monitor > e_modules-rain > e_modules-screenshot > e_modules-slideshow > e_modules-snow > e_modules-tclock > e_utils > eclair > engage > entrance > evidence evidence is borken anyway - regardless atm. > evoak evoak doesnt build anyway. > enlightenment > express > ewl they fail to BUILD or run? fail where? just edje_cc? in which case there is actually only 1 problem at hand at all - that buildrequires: need to add module packages. you could have just added requires: to the evas package to require the module packages too - so it sucks them in - but then the module package still CAN be built and DO exist and as a result can easily be separated later withotu havign to write all the sub-package spec entires. removing them means they have to be re-written. using deps i do see as a reasonable stop-gap measure till things settle. at least it doesnt throw out the ability to build separate packages. > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> > n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) > ----------------------------------------------------------------------- > "To err is human; to really louse things up requires Microsoft > products." -- Alexander Pope, slightly paraphrased > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
