[Build-common-hackers] Using CDBS' flavors mechanism to build packages

Emilio Pozuelo Monfort pochu at debian.org
Sun Dec 19 01:47:48 UTC 2010


Hi Jonas,

On 11/12/10 15:30, Jonas Smedegaard wrote:
> On Sat, Dec 11, 2010 at 02:09:58PM +0000, Emilio Pozuelo Monfort wrote:
>> I want to start using the CDBS' flavors support in packages that we
>> currently build multiple times with different configure flags / CFLAGS
>> / LDFLAGS... (e.g. gtk+, glib, pango, vte...).
>>
>> Can you point me to a package that uses this mechanism, so I can look
>> at how it's done? Or in the absence of one, can you explain it to me?
>> :)
>
> Source package libgd2 uses flavors explicitly.

That's exactly what I needed!

> python-xklavier, scenic, morituri, lash and a bunch of sugar packages
> use flavors implicitly through python-autotools.mk.

I have a bunch of those too, but I wanted that used it directly.

> You are quite welcome to post here to the list any question you might
> have with using thise relatively new feature, as I obviously have an
> interest in weeding out any bugs in it and encourage use of it. :-D

I'm giving it a try with vte, which builds the source multiple times (a normal 
build, an udeb build, one for each supported python version, and now an extra 
gtk+3 build). It's looks great, though it can still be improved a bit:

- I've seen that you've fixed the "honour DEB_CONFIGURE_FLAGS_$(flavor)" bug in 
git... would be nice to get that released.

- Currently I need to manually specify the install directory this way:
DEB_MAKE_DESTDIRSKEL = $(CURDIR)/debian/tmp/@FLAVOR@
DEB_DESTDIR = $(CURDIR)/debian/tmp/$(cdbs_make_curflavor)/
Would be nice if that was not necessary (or not that complicated). There's a 
FIXME in libgd2/debian/rules about it.

- Would be useful to be able to specify CFLAGS as CFLAGS_$(flavor), the same way 
as we do with DEB_CONFIGURE_FLAGS_$(flavor). Probably other variables like 
LDFLAGS, etc.

- I'm currently installing each flavour in debian/tmp/$(flavour), then in my 
debian/*.install files I list what I want in each package. This is fine, except 
that I have e.g.:

$ cat debian/libvte-common.install
main/usr/share/locale/		usr/share/locale
main/usr/share/glade3/		usr/share/glade3
main/usr/share/vte/termcap-0.0	usr/share/vte/termcap-0.0
gtk3/usr/share/vte/termcap-2.90	usr/share/vte/termcap-2.90

And I need to repeat the directory without the flavour prefix, otherwise things 
are installed in /main/usr/... That's a bit annoying. However it's really 
painful for python-vte.install:

$ cat debian/python-vte.install
python*/usr/lib/python*/*-packages/gtk-2.0/*

Here it's installing stuff in /python2.5/usr  and /python2.6/usr. I could change 
that to
python2.5/usr/lib/python2.5/site-packages/gtk-2.0/ 
usr/lib/python2.5/site-packages/gtk-2.0/
python2.6/usr/lib/python2.6/site-packages/gtk-2.0/ 
usr/lib/python2.6/dist-packages/gtk-2.0/

But when the list of supported python version changes my package would become 
buggy. I could do something hacky on debian/rules, but the point is that the 
prefix are making stuff painful. I've thought that it would be cool to have a 
-pN option to dh_install, similar to the patch -pN option :-)

> No need to cc me directly - sending to the list is enough. If I don't
> respond, then please simply email again to "poke" me, as I sometimes get
> overwhelmed by emails and don't get around to respond to them all.

OK. I CCed you just in case because the list archive was full of spam :)

Cheers,
Emilio



More information about the Build-common-hackers mailing list