Comment 33 for bug 723282

(In reply to comment #14)
> I was waiting for a fix for the Vala issue (which I just backported from Git
> yesterday), before finishing my Postler packaging -- sorry for the duplicate
> request!

Thanks for applying the Vala fix!

> Thomas, let me know if you'd like a comaintainer for this.

Sure.

> I have some differences in my specs:
>
> - CFLAGS needs to be manually exported; when packaging I searched for any

Right, I will fix that while importing the package (maybe in the evening).

> guidelines for packaging with waf (we still really need to write one!) Funnily
> all the people involved in that thread on the mailing list are here -- me, you
> (waf maintainer) and Christoph who started the thread.

There has been a long thread on the devel mailing list some time ago with no real outcome. Also see below.

> - waf build probably needs the -v option (verbose) -- that's how I discovered

The -v switch didn't work on my F13 machine, and caused waf itself to crash.

> the wrong compiler flags were being used, and %{?_smp_mflags}

Not really needed, as waf automatically builds in parallel, using as many threads as it finds cores. Maybe it's nevertheless a good idea to pass -j %{?_smp_mflags}, so koji has more control.

> - link against libdb-devel (BerkeleyDB 5) rather than db4

Why's that?

> - use system waf rather than the bundled version

This is something we shouldn't do (in general, for any package, that is). I was still hoping someone else filed a request for an exception at the packaging committee. But now that I also own a package using waf, so maybe I have to do it myself.

Postler bundles waf 1.5.X, but in rawhide we are at 1.6. I didn't thoroughly test whether there are incompatibilities for postler, but in general, each package should use its bundled waf copy and not the system one. As waf is a development tool and not some sort of runtime library, the usual security argument against bundling doesn't really hold. The bundled copy is what upstream has released and tested their package with, and deviating from that is not worth the effort.

> Also, I started using the virtual pkgconfig(...) rather than package names, as they match up with upstream's dependency checking better.

Will consider this.