[php-maint] Bug#443637: #443637 php5: FTBFS: recode extension can not be configured together with: imap mysql

[Steve Langasek]

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.
vorlon at debian.org                                   http://www.debian.org/