[Build-common-hackers] waf.mk and broken fakeroot debian/rules clean call in packaging-only branches.

Jonas Smedegaard dr at jones.dk
Wed Mar 30 09:24:46 UTC 2011

On Wed, Mar 30, 2011 at 10:27:28AM +0200, Emilio Pozuelo Monfort wrote:
>On 29/03/11 18:42, Krzysztof Klimonda wrote:
>> I can only assume that, as the problem seems new to you, the issue of
>> d/rules clean not working has never been raised here. So it means that
>> either all other maintainers are copying full source to the packaging
>> branch for the duration of work, only to remove it before commiting
>> changes, or it has always worked this way for other packages, and waf.mk
>> does things differently.
>It has always worked fine, because historically the clean target has
>ignored errors, see e.g. autotools.mk:
>and all the others.

Not all: Not hbuild.mk or scons.mk.  But generally, yes.

Two (or eight) wrongs don't make a right, though.  and that common style 
of simply relaxing the call is bad.

>I can't find anything in policy that says clean shouldn't fail if there 
>are missing files, but I thought it did, given e.g. dpkg source format 
>1 will ignore removed files when generating the diff.gz. I think waf.mk 
>should do the same and not fail if some files are missing, just try to 
>run "-./waf clean" or whatever it has to do, ignoring errors.

I also failed to locate a passage in Debian Policy about this, but 
recalled having seen something about it in a lintian warning once.  Last 
night I asked on IRC and someone mentioned that the lintian warning was 
about distclean - which helped me locate it using "git grep" on the 
lintian source.  The actual lintian warning can be displayed like this:

echo "W: foo: debian-rules-ignores-make-clean-error" | lintian-info

> A rule in the debian/rules file for this package calls the package's 
> clean or distclean target with a line like:
>  -$(MAKE) distclean
> or
>  $(MAKE) -i distclean
> The leading "-" or the option -i tells make to ignore all errors. 
> Normally this is done for packages using Autoconf since Makefile may 
> not exist. However, this line ignores all other error messages, not 
> just the missing Makefile error. It's better to use:
>  [ ! -f Makefile ] || $(MAKE) distclean
> so that other error messages from the clean or distclean rule will 
> still be caught (or just remove the "-" if the package uses a static 
> makefile).

I therefore agree that we should try(!) to handle gracefully the waf 
file missing (thanks for insisting, Krzysztof!), but I disagree that we 
whould do it by simply adding a leading dash.

...and we should fix the existing too relaxed snippets while at it.

I imagine introducing a new variables DEB_CLEAN_RELAX and 
DEB_MAKE_CLEAN_..., DEB_SCONS_CLEAN_... etc. to allow mixing classes and 
override only some of them).  The content of ...RELAX_PREFIX is then 
prefixed relevant clean rules when ...RELAX is non-empty.

I fear this will trigger a pile of FTBFS so wonder how to best proceed.

 a) DEB_CLEAN_RELAX=1 by default
 b) DEB_CLEAN_RELAX=1 by default with warning until weezy release
 c) DEB_CLEAN_RELAX unset by default

What do you think?

 - Jonas


Please respect the dual CC as requested by Krzysztof!

  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20110330/4fb3766d/attachment.pgp>

More information about the Build-common-hackers mailing list