[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bootstrappable Debian - proposal of needed changes



+++ 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/


Reply to: