On 11/3/20 11:02 AM, Christoph Berg wrote: > Re: Sebastiaan Couwenberg >> No, we explicitly added the templating bits to support this use case. > > Iirc the reason it was copied from pgxs_debian_control.mk to support > "NEWEST_PGVERSION".
I've had this discussion with Markus before, the templating in d/rules was the solution to building postgis in stable systems. >>> Calling clean was already triggering the control generation: >>> >>> override_dh_auto_clean: debian/control >> >> While that also changed d/control outside the chroot, it didn't call >> `pg_buildext checkcontrol` which fails due to those changes. > > That part is necessary to make builds fail if control would change. It > doesn't matter if the change is triggered from clean/configure/build. d/control changes on stable systems where and older postgresql version is installed outside the chroot where the clean target is initially called. d/control doesn't change inside the chroot. d/control only changes inside the chroot when we haven't updated the package yet for a newer postgresql. >> AFAIK only the clean target is suitable, as configure shouldn't modify >> d/control. Every package that generates d/control has that file a >> dependency of the clean target. >> >> Making `pg_buildext checkcontrol` optional may be a solution for stable >> systems. > > If the spurious change on stable is not a problem, and you just want > the build not to fail, you can set PG_UPDATECONTROL=yes. Or revert the d/rules back to what we had before. I don't what to have to set the env var when building postgres related packages. So setting it in d/rules is what I'm tempted to do instead. -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 _______________________________________________ Pkg-grass-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grass-devel
