+++ Michael Biebl [2013-01-25 15:31 +0100]: > Hi, > > looking over your proposal, I was missing a few things (sorry if this > was mentioned in one of the replies, I've only skimmed over the thread). > > a/ It's good practice to explicitly enable/disable features via > configure switches, to have reliable build results in tainted build > environments. What's the plan to annotate such optional features and > manage the configure switches in debian/rules?
Build profiles can be viewed as being (to a large degree) a mapping of configure options into debian packaging. So we get some of the flexibility that configure provides exposed in the packaging. We don't want the feature that stuff will get randomly skipped if support is not found, just the ability to turn some things off for reasons like bootstraping and crossbuilding, and potentially embedding and other downstream distro variation. As you say: explicit enabled/disable is good, because determinsitic builds are wanted. So a typical rules snippet looks like this: ifeq ($(DEB_STAGE),stage1) DH_OPTIONS += -Nlibdb5.1-sql CONFIGURE_SWITCHES += --disable-sql else CONFIGURE_SWITCHES += --enable-sql fi so that explicitly sets whether to enable the sql bindings and skips building the package if not. > b/ You mentioned documentation (gtk-doc) as optional build dependency. > Same packages do not ship the documentation in a separate binary > package, but as part of the -dev package. Is there an idea to annotate > optional files in .install files, so dh_install will not fail if files > are missing when building certain profiles or is there an alternative > idea how to handle this? No, there is no plan for this. Anything is possible in rules files. On some packages we can turn off -fail-missing to avoid build failures. Ultiately you can do what you like in the packaging, but it helps a lot if it's neat and not intrusive, which is why -N<package> in debhelper options is great. I'm not aware of a nice neat way of using a different .install file, or concatenating segments of .install files but it would be nice to have a declarative way of specifying this. It has not been a significant issue so far, but I expect you are right that there will places where it's pretty ugly. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130130165517.gr5...@stoneboat.aleph1.co.uk
