On Tue, 24 Jan 2006 14:33:25 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled:
> On Tuesday, 24 January 2006, at 10:23:57 (+0900), > Carsten Haitzler wrote: > > > 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 > > Among linuxdevices READERS ONLY. That's hardly scientific. it's still better statistics than you have :) fact is - rpm based rh/fedora systems ARE being used for specific device creation - evas is geared to help with that. > Even so, when was the last time you heard of RedHat or Fedora using > anyone else's spec files? Don't you remember the Imlib2 fiasco? They > created their own spec file WITHOUT all the separate module packages, > and it caused problems with other packages (like Eterm) that required > the loader packages. no - i dont remember the fiasco. that is bad - VERY bad. thats what i call abysmal packaging. sheer laziness. > > 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. > > I can imagine a lot of things too, but I asked for a Real World > example. You have yet to give me one. Some project or product you > KNOW is using evas and using RPM as a package manager. it's very unliek you mej to try and be "real world". i know u love to be pedantic. i'm being pedantic. the way u have packaged evas up now with the changes means evas NEEDS things it actually doesn't NEED. the toosl and applications ABOVE it should determine that need via dependencies - not evas itself. thats is the CORRECt way to do this. because of errors as a user (not installing any useful modules) you have decided to just create a massive package with everything chucked in u forgot to install as opposed to putting such dependency information in the RIGHT place. > > and now the fiels will not just fail to build - but dump meaningful > > errors to let you know you may need more modules. > > Yes, I saw that. That's a big step in the right direction. > > > 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". > > Most RPM's don't install tar.gz files either. One way or another, the > packages will HAVE to know the deps of the .edc (or .edj) files. > Otherwise stuff just won't work. and edje defines this now - i added them. i shoudl split edje up into 2 instead of 2 packages too as i mentioend before. now i repeat my point - you solved a problem the WRONG way. instead of removing 50+ lines of spec file - you shoudl have added 5 or so lines in total to a few other spec files listing extra dependencies. > > see above. > > Ditto. > > > > evidence is borken anyway - regardless atm. > > Not true. It built just fine for me after David's patch was applied. after the patch - sure. but evidence is broken until that patch going into it. > > > enlightenment > > > express > > > ewl > > > > they fail to BUILD or run? > > They failed to BUILD. > > > you could have just added requires: to the evas package to require > > the module packages too - so it sucks them in > > We've been through this before. Remember Imlib2? That sort of crap > had to be undone there too. no - i don't remember. imlib2's spec file still build loader module packages... when i looked a few days ago. > > 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. > > Nothing has been thrown out. The module packages can be added back in > easily once everything else is ready. sure - if you want to add it all in - why remove it all, and not just add DEPENDENCIES to suck them in? > But let me ask this: Once an .edc file has been turned into an .edj > file, what modules are required at runtime to load the images in those > files, if any? Is it enough to have those modules (esp. > engine-buffer) at build time? once a .edj file is compiled u only need the eet image loader module. nothing else is "required". the png, jpeg loader & saver moduels and buffer enginer are nonley needed by the edje_cc/edje_decc etc. tools. only edje and edje_test suck in the software_x11 engine module as a minimum req. thats why i mentioned before breaking this up into smaller fine-grained packages as edje really NEEDS very little runtime. :) > 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) > ----------------------------------------------------------------------- > "Map out your future, but do it in pencil." -- Jon Bon Jovi > > > ------------------------------------------------------- > 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
