> > Maybe I expressed myself wrongly or wass too quick at writing something. > > RPM has very good capabilities of automatically finding dependencies > for libraries. > > e.g if you state that package X: > > BuildRequires: edje-devel > > Only stating this would imply for a tool like yum/apt to automatically > download edje for RUNNING the application. > > i.e if you type: yum install X > Then you will get > > X depends on edje... ready to download. > 1.edje > 2. X > Proceed? > > now if you want to rebuild X src rpm, then it will tell you that you > need edje-devel to rebuild it. So it comes back to me saying that > putting something like this; > > BuildRequires: edje-devel > Requires: edje > > is NOT necessary. RPM will download the non-devel package > automatically. But something like this is OK: > > BuildRequires: edje-devel > Requires: xine > > Now this means that it doesn't require xine-devel to BUILD but > requires xine to RUN. > In such a system, a yum install X would download: > > 1. edje > 2. xine > 3. X > > http://fedoraproject.org/wiki/PackagingGuidelines#Requires >
Hey, I just said it would work, I said nothing about proper or clean :-P Actually that's good to know and thanks for pointing it out. I've been doing things the other either for habit or because I picked up the incorrect method somewhere along the line. In any event, I think things are far enough along at this point that raster isn't just going to wipe the whole code base and call shenanigans on everyone. My co-worker and I have begun putting things in rhel/centos and mandrake specific packages to get things ready for transition to actual release (yeah, I know it might still be a while out). Mostly it's been going through eaps etc to get Window class and application paths correct, as well as going over Makefile.am's and specs to ensure that things build cleanly in a chroot. There are still a few minor bugs in the specs that are out there for chroot building, but I'm not sure if they should be submitted or just considered a distro patch and left for packagers to deal with. Thanks again for bringing that to my attention. -- Jim Perrin System Administrator - UIT Ft Gordon & US Army Signal Center ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
