Updating waf to 1.6

Toshio Kuratomi a.badger at gmail.com
Sun Jan 16 21:31:54 UTC 2011

On Sun, Jan 16, 2011 at 10:16:37PM +0100, Thomas Moschny wrote:
> 2011/1/16 Jon Ciesla <limb at jcomserv.net>:
> > Would you be so kind as to file BZs against midori and xiphos indicating
> > that they either need to switch to using system waf or file a Trac with
> > FPC for an exception if there's a really good reason to bundle?
> Could do that, but I think we should ask FPC for a general exception.
> waf is intended to be bundled, and its api changes from time to time.
> waf's upstream even officially discourages installing it system-wide
> (and has removed the installation routine in later releases). Some
> people might find an rpm handy nevertheless, that's why we still
> package it, while e.g. Debian has stopped packaging it. Forcing our
> package maintainers to use system's waf (which might be a on different
> version than that embedded in their source tars) might put extra
> burden on them and is probably not worth the effort - we are talking
> about a build system, not a run-time lib.
It's possible that it could be shown to be a copylib:

But waf does make periodic releases so that might not be the right
exception.  If you could draw parallels between the autotools and waf, that
might be a way to look at it.  I'll note, though, that the autotools have
a layer that is used to create the build scripts which should not be bundled
(autoconf, automake, and the like), and a layer that is the actual build
scripts (configure.ac, Makefile.am, etc) which are bundled so we'd need to
figure out if waf should fit that same mold.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20110116/f6ab7b55/attachment.sig>

More information about the epel-devel-list mailing list