[Build-common-hackers] a WAF class for CDBS

[Jonas Smedegaard]

On Mon, Dec 27, 2010 at 12:16:02AM +0100, Rémi Thebault wrote:
>Le samedi 25 décembre 2010 à 22:18 +0100, Jonas Smedegaard a écrit :
>> I recommend to support global, package-default and per-package vars
>
>I use $(cdbs_curdestdir) in common-install-impl target. I tried
>something with calling cdbs_expand_curvar, but no success.
>the  var isn't expanded as I expected. I commented out for the moment

Perhaps if you elaborate on what you tried, I can help figure out what 
went wrong - and we can learn if something is broken or you 
misunderstood how to use it.  In other words: maybe documentation just 
needs to be improved :-)



>> You mention that to use it needs including debhelper.mk.  That's not 
>> true - it works perfectly fine without CDBS'ifying debhelper too.
>
>building and staging works, but cleaning let some files in the debian
>dir (the stage is one of them)
>and the binary deb file isn't built without debhelper.mk. Is this
>behaviour desired ?

CDBS is a range of skeleton files to ease various facets of packaging.

Users may want to use a single or several of them.  The purpose of the 
waf snippet is to handle waf-related routines, not do everything related 
to packages which only use waf.  Then including debhelper.mk would not 
be enough - you should also mention that a copyright file was needed, a 
control file, etc. etc.



>> ...but really it is more elegant IMO a) do the checks separately (the 
>> -a might not be POSIX compliant although in recent Debian this 
>> restraint might be relaxed) and b) only check in initial targets.  
>> Like this:
>>
>>    # ensure waf is executable
>>    pre-build clean::
>>            test -f ./waf
>>            test -x ./waf
>>
>
>Done. I created a new target (cdbs-waf-sanity-check) upon which depends
>configure and clean targets

Better.  But why check at each step instead of once per build as I 
suggested above?



>> As a sidenote, I really dislike the fundamental design of waf: 
>> Shipping a self-extracting scripting environment, obfuscated by an 
>> odd format, and telling users to execute that code blindly.  It is a 
>> security risk!
>>
>> We really should extend the initial check to e.g. keep a checksum
>
>Do you mean keeping track of a checksum in cdbs source code ?
>If yes, it means we must keep an eye on every waf new release. I don't 
>think it could work on long term.

I mean storing a checksum in e.g. debian/waf.sha1sum inside each source 
package.

It might require updating each time there is a new upstream release, 
yes.  And not us, but the package maintainer need to keep an eye on it - 
which is needed in any case due to the insecure design of waf.  What we 
offer is a mechanism to ensure it is not forgotten: I suggest that we 
make the build routine FAIL if checksum does not match, which means the 
package maintainer must do the needed security scrutiny each time the 
waf blob changes, or explicitly do the foolish act of suppressing our 
safety mechanism.


>> Much better would be a separately packaged waf tool.  This has been 
>> tried, but upstream obstructed that to the extend that it has now 
>> been dropped from Debian.
>
>This would be ideal, but the Waf user guide itself discourage a 
>system-wide installation and advice to ship it in the tarball source 
>tree

I know.  This is what I wrote has been tried.  And not only did upstream 
discourage in documentation - they actively coded in a way to 
deliberately obstruct the work in Debian to make a system-wide waf!

Waf is bad.  Tell it to all your friends.  And let us do what we can to 
make it safe to use in Debian.



-- 
  * 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/20101227/96dbb41a/attachment.pgp>