On Sun, 2003-04-06 at 14:09, Jean-Michel Dault wrote:
> Le dim 06/04/2003 à 16:26, Stefan van der Eijk a écrit :
> > I've written up on an issue with rpm dependencies in -devel packages. 
> > I'm not sure if the story is 100% accurate (I'm not a programmer), so if 
> > you've got a moment to spare, feel free to review it.
> 
> Very interesting...
> 
> It would solve also a lot of problems in complex applications with
> conditional compiles. 
> 
> For example, php-gd can be linked with png, xpm, gif, and other graphic
> formats, but some are optional. The usual way to find what's required is
> to use the ./configure script, and check the output to see what it's
> looking for, or check the m4 macros.
> 
> Having to mandatory run a check on the include files would tell us
> what's potentially needed to make the package. Of course, you should be
> able to override this. 
> 
> For example, the zlib package can optionally include windows.h, which we
> obviously lack ;-) Hence:
> check-required-includes --exclude="windows.h" would grep the zlib
> source, and return all needed .h files, except windows.h. RPM could then
> add these files as BuildRequires.
> 
> We could also, for -devel packages, have a check-provided-includes
> script, that would add all .h and .so files to Provides. I wouldn't
> bother with -static-devel, since very few packages need these.
> 
> Thus, if we attempt to rebuild zlib without glibc-devel, rpm-build would
> show that these requires are not met:
> /usr/include/sys/types.h
> /usr/include/sys/unistd.h
> ...
> /usr/include/stdio.h
> 
> It's important that the requires are on full path, because, in the case
> of types.h, many packages can provide this file, but you wouldn't want
> it to be linked to dietlibc-devel (otherwise you'd override it).
> 
> > http://eijk.homelinux.org/~stefan/rpm_devel_dependancies.html
> > <http://eijk.homelinux.org/%7Estefan/rpm_devel_dependancies.html>

Stefan

   Quick look looks very nice.  One minor point is that this is most
accurate for src rpms... slightly less so for binary, but admittedly I
haven't had a chance to really look into what it's saying in detail.. 
Seems well written too.  Thanks.

James
 
> 
> Comments/flames welcome.


Reply via email to