>> True. What I've noticed (at least at MDK) that people aren't >> interested in a clean build environment. They just want their >> packages to build and not to worry about (useless?) stuff like >> BuildRequires.
> no. we're many that're happy with better buildrequires/requires. > but this is less important than having fixed bugs or development. > always the same ressources problem. >> due to the fact that the dependancies for -devel packages are not >> automatically found it's difficult (if not impossible) to maintain. > yes >> recently the libart_lgpl2-devel has been created. I beleive that the >> files in this package used to be part of the kdelibs-devel or >> kdebase-devel packages. Now the package is split off. Now quite some >> packages that BuildRequire kdebase-devel or kdelibs-devel are not >> compiling due to the fact that the dependancies have been broken. > this is the problem of kde being not splited at first Well... It's true that this issue showed up when these packages were split up --> it broke the dependancies. IMHO what is needed is a dependancy system that defeats these things from occuring. The BuildRequires of a package should still point to for instance libpng-devel. But when libpng3-devel is built, it should be able to find the dependancies the files it carries require (and provide). just grep for "include" in one of the header files in the package. And the dependancies become clear. $ fgrep include /usr/include/png.h * We must not include leading zeros. /* include the compression library's header */ #include "zlib.h" /* include all user configurable info, including optional assembler routines */ #include "pngconf.h" /* Finish a chunk started with png_write_chunk_start() (includes CRC). */ #include <crtdbg.h> This shows that libpng-devel requires zlib.h and pngconf.h. Where zlib.h is outside of the package --> a Requires. png.h can be put down as a Provides. If something like this is put in place (this is just an example) then the dependancies between -devel packages won't need to be maintained manually. And problems when splitting packages won't have an impact on other parts of the distro. perhaps this perl module http://search.cpan.org/author/AMICHAUER/C-Include-1.40/Include.pm can help to implement this. What do you think? Stefan
