> 
> 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

Reply via email to