> > which causes packagers to resort to either resort to build-require > > "bison m4" or "byacc" instead of "bison". This is a bug in the old bison package and it should have been re-issued as an update IMHO. Under no case should m4 be added to a buildrequires unless that package actually uses m4. Otherwise you muddy the real requirements for a package. >> Your buildsystem should always require m4 until our source base is cleaned >> up to support this fine-grained level of requirements. Until now it is not. I disagree with this. Very few packages actually use m4. Because you have people that need bugs fixed when no updates are provided, its pretty common for people running an old RH system to get the latest package and build it on their system. Therefore, the baseline has to be enforced by rpmbuild. m4 is not required by rpmbuild. Another thing, you have to be careful not to add too many programs to the baseline development requirements. Otherwise you lose the tracability of what contributes to each package. Suppose one day that a bad version of m4 was released and m4 was a common requirement. You would not be able to trace all the packages that might be affected. >I've applied a few buildreq fixes from Steve Grubb, hopefully I'll get his >next set soon and can carry on merging them. Yes, next batch is being sent. I have the full & exact buildrequires for about 220 packages. My buildsystem borrows some ideas from LFS. It can bootstrap build a distribution from a host system like a stripped RH9. When I started this project back in March, my buildsystem showed FC only needed 6 passes to get all the packages build. There were many missing dependencies and circular dependencies. It did not build to completion. I started correcting everything. Now, my buildsystem shows 19 passes to get all packages built. It consistently builds now. You can look at the build dependency diagram (not the runtime dependencies) from here: http://www.web-insights.net/dep.ps.gz I recommend KGhostview, but any ps viewer should do. Simple packages are at the top, packages that depend on many prerequisites are at the bottom. Speaking of runtime dependencies. I was researching a security related bug the other day and ran across a neat feature of bash. --rpm-requires will print out the external programs called by a sh script. I started comparing the runtime requirements of shell scripts versus what is stated. For example, /sbin/grub-install. The grub package states bash & texinfo. I get coreutils, diffutils, grep, and sed just for that one file! It would be nice if rpmbuild scanned for shell scripts, capture the info, resolve the files to a package, and add the packages to the runtime requirements. Its really simple. http://www.web-insights.net/sh2rpms if you want the bash script. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
