Itai Zukerman <[EMAIL PROTECTED]> wrote: >A few days ago I had to rebuild gimp1.1 from source to fix a little >bug that was stalling my work. I noticed that since I have LPRng >installed on my system, ./configure came up with different settings >than the gimp binary in the archive was compiled with (specifically, >lpstat support was enabled in the print plugin). > >Now it occurs to me that if I were to NMU this package (which I have >no intention of doing!), I will be uploading a binary package >significantly different from the one in the archive. I imagine this >is the case for a great many packages that rely on ./configure and >having certain software installed (I don't expect gimp to build-depend >on lpr!). Is there a solution to this problem?
It should be possible to force the configure script never to enable the feature in question: --disable-lpstat or whatever. If not, the configuration system should probably be patched so that you can. Anybody should be able to install all the build-dependencies, build the package, and get the same result as before (assuming they have the same version of all the build-dependencies as the maintainer). If they can't do this with a particular package installed, I'd say that e.g. gimp would have to declare a Build-Conflicts: against lprng; we don't want alternate versions of gimp depending on lprng as maintainer and non-maintainer uploads are made. This is pretty undesirable, though. Build-time relationships can be surprising. I recently rebuilt my (as yet unofficial) trn4 package, having recently installed heimdal-lib to satisfy some dependencies, and found that the baroque upstream Configure script looked for a libhdb, presumably to support some other Unix system; unfortunately, libhdb is part of heimdal-lib on Debian, and since I didn't have the relevant development packages installed the build then failed. As a workaround, I added a line to debian/Policy.sh to specify exactly which optional libraries I wanted to be used. -- Colin Watson [EMAIL PROTECTED]
