Bug#660193: developers-reference: please suggest debian/rules target name for preparing source

[Carsten Hey <carsten@debian.org>]

* Henrique de Moraes Holschuh [2012-02-18 10:11 -0200]:
> On Fri, 17 Feb 2012, Carsten Hey wrote:
> > The intention of this bug report is to unify the name of a target
> > that might be used more often soon, and it is not sufficient to
> > reach this goal if we rely on package maintainers to document the
> > target they use in debian/README.source.
>
> I have nothing against separating the clean target into a "prebuild"
> target (that will have to run when the clean target is invoked for the
> first time at the very least).  But I do wonder how useful this
> separate "prebuild" target would really be?   You still need to run
> the clean target anyway to do anything useful...

I think I made my point in this bug report not clear enough, but I found
an other example [1] where this target could be used.  I hope this makes
the bug report more clear.

Using the build tool waf in the way intended by it's upstream in
a Debian package contradicts Debian's goal of being able to adapt source
packages easily.  Although not recommended, shipping the unpacked waf
sources in a Debian source package is one possible way to handle this.

The steps to unpack the waf sources can be put into a new debian/rules
target that is only run on the maintainers system before running
dpkg-buildpackage, either after doing a VCS checkout or whilst packaging
a new upstream version:

73a74,85
> 
> override_dh_clean:
>       find wafadmin -name "*.pyc" -delete
>       dh_clean
> 
> prebuild:
>       test ! -d wafadmin
>       ./waf --help >/dev/null
>       mv .waf-*/wafadmin .
>       rm -f .waf-*/t.bz2
>       rmdir .waf-*
>       sed -n -i -e '1,/^#==>$$/ p' -e '/^#<==$$/,$$ p' waf

The target name in the normal diff above is 'prebuild', it could also
have been 'extract-waf'.  All this bug report is about is that in such
cases maintainers should consider using prebuild as the target's name
instead of inventing new ones.

Footnote [2] contains additional notes only relevant if one wants to
extract a waf file.


Regards
Carsten


 [1] additional to reducing build dependencies in essential packages and
     avoiding differences on different architectures on multiarch same
     packages

 [2] - This example requires some changes in debian/source/*, e.g.:
         debian/source/format:3.0 (quilt)
         debian/source/include-binaries:waf
         debian/source/options:auto-commit
     - Putting the extracted waf source into an additional upstream
       tarball instead of a diff might be an alternative to consider,
       this could be automated too.
     - New upstream versions might require adapting the filenames in
       debian/rules' targets override_dh_clean and prebuild.
     - I'm not sure if ftpmaster would be happy with the blob in the waf
       script if it is still would be shipped in the .orig.tar.gz, but
       IMHO providing a short shell or perl script to convert this blob
       to a tarball without relying on waf extracting itself should be
       sufficient to make them happy.
     - I would not consider the according waf bug to be fixed unless it
       documented in README.source in a proper way.