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

[Jonas Smedegaard]

Hi Emilio,

On Sat, Apr 02, 2011 at 04:58:48PM +0200, Emilio Pozuelo Monfort wrote:
>On 30/03/11 11:24, Jonas Smedegaard wrote:
>>>  [ ! -f Makefile ] || $(MAKE) distclean
>
>> 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.
>
>So something like e.g.
>
>[ ! -f waf ] || ./waf clean
>
>(or however waf clean is called, I'm not familiar with it).

Yes.  Sorry for being vague.


>Sounds good to me.
>
>> ...and we should fix the existing too relaxed snippets while at it.
>
>I'm fine with that too, as long as we keep supporting `debclean' with 
>only a debian/ folder (this is the usual way to do packaging with 
>svn-buildpackage, and there are probably 1000+ packages in the archive 
>packaged that way).

My aim here is to improve reliability when invoking build rules (in 
particular those triggered by the clean target) in a fully prepared 
source tree.

Preserving or improving reliability of invoking build rules on 
half-baked source packages is only a possible added bonus.

If reliability is an issue, then use --svn-export or --svn-dont-clean 
option to svn-buildpackage, or whatever else pre-building tricks 
necessary to establish a fully prepared source tree before invoking 
build rules.


>> 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?
>
>I'm not too sure what changes you mean that would cause FTBFS. Can you 
>say a real example?

Packages with unusually named makefile.

For makefile.mk (and derivatives) DEB_MAKE_MAKEFILE is only optional, so 
we can only rely on testing its existence at clean time when set.  
Particularly for that snippet I believe it is safe to fall back to 
checking for GNUmakefile, Makefile and makefile (in that order).  I just 
imagined that logic to turn out to be flawed for some corner cases, or 
similarly so for other snippets.


>> Please respect the dual CC as requested by Krzysztof!
>
>The CC wasn't in his mail.

If nitpicking then you are right: Krzysztofs first post omitted Rémi - 
his second (which you replied to) was To: Rémi and Cc: the list.


  - Jonas

-- 
   * 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/20110402/733605f2/attachment-0001.pgp>