On Thu, 30 Mar 2006 08:13:09 -0800 "Blake B." <[EMAIL PROTECTED]> babbled:
> > On Mar 30, 2006, at 6:12 AM, Carsten Haitzler (The Rasterman) wrote: > > >>> > >>> ok. i think i might have to poke my finger into it all too - i > >>> notice some > >>> totally outrageous "build requirements" (ecore REQUIRES > >>> libdiretfb? no - > >>> it's optional and i don't think we should be shipping it as then > >>> the final > >>> e install will drag in dfb w2hen actually no apps "use" it - it's > >>> there for > >>> special case development). also packages need splitting up into more > >>> fine-grained lumps > >>> > > Definitely. Evas needs to be done this way too. I didn't notice the > directfb requirement in there, I build without it. I think xstasi > must have added it because his repository has support for it (and a > back-ported directfb package) aaah. i think a dfb enabled ecore is certainly an option - but shouldn't be a general case imho :) > >> if there're no objections i'll split libecore0 into the following > >> packages (which will hopefully fix the dependency issues as well): > >> > >> libecore0 > >> libecore0-config > >> libecore0-con > >> libecore0-dbus > >> libecore0-directfb > >> libecore0-evas > >> libecore0-fb > >> libecore0-file > >> libecore0-ipc > >> libecore0-job > >> libecore0-txt > >> libecore0-x > >> > >> are there packages which can be merged into one? > > > > i like the split this way. it gives fine-grained control. auto- > > dependency > > resolving will make sure the right subset is installed. > > Cool, will libecore be a virtual package for all of them? Or > something like libecore-all? well there is a libecore as such already... i'd say libecore-all can be that. > > > >> libecore0-dev will contain all available headers, as it is right > >> now. or > >> should i split that one, too? > > > > it will have to suck in all the above libs then. > > I think this is fine, since IMO anyone wouldn't be doing much > development with only one specific subsystem of ecore. And not to > mention maintaining all those different packages for -dev AND lib > will be a pain. yup. the main thing is that at RUNTIME a user is not forced to suck in dependencies he/she does not need (installing e17 - they dont need/want directfb for example). if someone makes some server monitoring tool that runs on servers using ecore +ecore_ipc - they dont NEED to suck in evas, x, dfb, etc. :) > -Blake > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
