On Thu, Mar 30, 2006 at 08:13:09AM -0800, Blake B. wrote: > > 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) > > >>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? > good question. as it is now, libecore0 just contains the basic infrastructure for the rest:
[...] ./usr/share/ecore ./usr/share/ecore/fonts ./usr/share/ecore/fonts/fonts.alias ./usr/share/ecore/fonts/fonts.dir ./usr/share/ecore/fonts/Vera.ttf ./usr/share/ecore/fonts/VeraBd.ttf ./usr/share/ecore/fonts/VeraBI.ttf ./usr/share/ecore/fonts/VeraIt.ttf ./usr/share/ecore/fonts/VeraMoBd.ttf ./usr/share/ecore/fonts/VeraMoBI.ttf ./usr/share/ecore/fonts/VeraMoIt.ttf ./usr/share/ecore/fonts/VeraMono.ttf ./usr/share/ecore/fonts/VeraSe.ttf ./usr/share/ecore/fonts/VeraSeBd.ttf ./usr/lib ./usr/lib/libecore.so.1.0.0 ./usr/lib/libecore.so.1 the fonts remain another issue (see last mail). i could add a virtual libecore0-all package but that shouldn't hold us back from adjusting proper specific ecore dependencies of apps/e, apps/entrance and so on. ditto for evas when it's ready, of course. if the previous commit in ecore is ok then i'll look into apps and libs which use ecore and fix the deps there. > > > >>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. > i totally agree. Falko ------------------------------------------------------- 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
