> > >Yes, that's what I mean. Adding rpm-build is kinda like adding gcc to, >say, 70% of all Mandrake packages. > The main problem is, there is *NO* policy or guideline on this. (I've requested that this issue is taken on, I beleive GC forwarded one of my e-mails to the MDK descision makers, I've yet to hear the result).
For BuildRequires I do the following: - All "top-level" BuildRequires (i.e. no redundant ones --> if gcc-c++ is required, then there's no need to add gcc and gcc-cpp) - Remove BuildRequires of basesystem packages (these should always be on the system) - Remove BuildRequires of rpm-build (otherwise you can't build an rpm) Maybe it's an idea for the policy / guideline... As for gcc, it should be added to the BuildRequires if required, eventhough many packages require it... >>I'd like to have a setup where I only need to specify one package and >>get a whole set of needed development packages installed right away. >> >You have already made it clear. Agreed. > As long as it's a technical solution. I've been hearing to many assumptions like "gcc ought to be installed", "it's obvious", etc. etc. If we're serious about the product and on maintaining it on multiple platforms with little effort, then keeping this stuff accurate makes sense (really!). >>Or would it be correct if I'd Require: *every* package that the new >>package needs? With this I mean, that I'd require glibc, bash, >>filesystem, rpm .... >> > >Definitely not. These are requirement of basesystem, and the whole >system won't run well at all without these stuff. > Exactly. >I have some basic idea on how to determine the requirements of devel >packages: > >1. parse foobar.la and foobar.pc, see if any libraries/.pc/.la files are >listed as requirement. These are non-versioned dependencies. > >2. grep '^#.*include' /usr/include/foobar, see if any headers are >required by the specified devel package. These can be versioned or not, >depending on content of configure.in. > >Stefan, any comment? > We've had a brief discusion about the Requires on -devel packages... It's difficult. I've got a little theory about this. It all didn't exist when we didn't have the -devel packages. Everything was in one package (not two), and rpm & dependancies worked fine with that. Now we've got these -devel packages, and things need to be added manually (it seems). This is a real pain. I just wish that there would be some way to teach rpm to figure out the provides / requires for the -devel packages like it does for the "non-devel" packages (maybe using the provides / requires information from the non-devel package is an idea, or making rpmlint smarter?). A quick example: I myself made a major f*ckup with the SDL packages lately. Instead of adding the Requires of alsa-lib-devel and esound-devel to the SDL-devel package (where it belongs), I went ahead and updated all the packages that BR SDL-devel. Quite stupid, right? If somebody adds the Requires to the SDL-devel packages, then we have a lot of packages with redundant BuildRequires (it's cosmetic --> doesn't hurt). Stefan
