[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:
[snip]
>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_CLEAN_RELAX_PREFIX (inherited as e.g. DEB_MAKE_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
P.S.
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