[Debian GNUstep maintainers] Misc issues with gnustep-base

[Eric Heintzmann]

Le 30/09/2017 à 09:54, Yavor Doganov a écrit :
> Eric Heintzmann wrote:
>> I vote for the "gencontrol" script.
> IMHO this is the worse solution, because the variables are defined in
> debian/rules and are not immediately available to shell scripts.  Here
> is an example script (sorry for pasting it inline but the mailing list
> is configured to reject attachments):
>
> ,----
> #!/bin/sh
> # Generate debian/control from debian/templates/control.m4.
> # The script must be invoked from the top source directory without
> # arguments.
>
> set -e
>
> # Read variables defined in debian/rules.
> v_objc=${1:-$(debian/rules -qp | awk -F' := ' '$1=="v_objc" {print $2}')}
> v_make=${1:-$(debian/rules -qp | awk -F' := ' '$1=="v_make" {print $2}')}
> sov_base=${1:-$(debian/rules -qp | awk -F' := ' '$1=="sov_base" {print $2}')}
>
> m4 -DV_OBJC=$v_objc -DV_MAKE=$v_make -DSOV_BASE=$sov_base \
>    debian/templates/control.m4 > debian/control
> `----
>
> In this case, the other change in debian/rules would be to define the
> variables with the "export" directive so that they propagate to the
> shell when genscript is invoked within debian/rules.
>
> But the problem is much more serious than the current inconvenience
> with the manual generation of debian/control.  The previous version of
> the rules was convoluted, but it ensured that debian/control is always
> up-to-date.  I just bumbed debhelper to 11 in control.m4 and the
> package was happily built.  This is completely unacceptable, it should
> have choked with unsatisfied build-dependencies.  Therefore I suggest
> to override dh_testdir in order to ensure that any changes are taken
> into account before building the package.  WDYT?
>
>

Something like that ?

|override_dh_testdir: # generate control file m4 \ -DV_OBJC='$(v_objc)' \
-DV_MAKE='$(v_make)' \ -DSOV_BASE='$(sov_base)' \
debian/templates/control.m4 > debian/control dh_testdir |||

||

||||

||