On Sat, Oct 13, 2007 at 01:27:03PM +0300, Damyan Ivanov wrote: > List night debugging of this, with the help of Atomo64, seanius and > vorlon, led to the conclusion that the build system is broken due to the > suhosin.patch & others changing files in incorrect order.
> Thing is, that configure needs to be re-generated in order to avoid the > "recode extension can not be configured together with: imap mysql" error > and replace it with just a warning. > On amd64, due to its hi-res stamps, configure is not re-generated and > so we have the error. > OTOH, re-generating configure (and main/php_config.h.in) overwrites the > patches applied to them so it can't be left for build-time. > vorlon promised to take a look. I'd very much like to see this fixed > "properly", which will have educational effect too :) > My ideas for the fix include yet another patch, that is applied before > most of the rest, that applies the changes to configure and > main/php_config.h.in so there won't be a need to re-generate them in > non-controlled environment (a.k.a. buildd). This would require > reordering of the patches, all patches that modify configure > pre-requisites should be applied before the configure patch for example. > As a nice side effect, auto* may be dropped from build-dependencies. Dropping auto* from the build-deps is a nice side-effect, but the not-nice side effect is the very large patch to the autogenerated files which results, as you noted in your subsequent message. I've gone ahead with applying a different fix to svn, which consists of: - remove configure and main/php_config.h.in from the suhosin patch - remove these autogenerated files in the clean target (instead of re-running buildconf --force, which is not guaranteed to revert the changes), which gives a warning when building the source package but otherwise results in a clean diff.gz. Stowing the autogenerated changes in a Debian patch is also valid, but one of the concerns I have with that approach is that, especially in a large team, maintainers may forget to regenerate the configure script after making changes affecting configure.in or the like. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
