[Build-common-hackers] a WAF class for CDBS
dr at jones.dk
Sun Dec 26 23:59:37 UTC 2010
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
>> 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
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
>> 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
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
Size: 836 bytes
Desc: Digital signature
More information about the Build-common-hackers