Re: Bootstrappable Debian - proposal of needed changes
+++ Matthias Klose [2013-01-16 21:09 +0100]:
> Am 16.01.2013 17:26, schrieb Johannes Schauer:
> > On Wed, Jan 16, 2013 at 04:00:15PM +0100, Matthias Klose wrote:
> >>
> >> So it does make sense to build with two profiles like stage1 & check.
Yes. I can think of situations where being able to specify more than
one profile at a time would be useful/flexible. stage1 & cross for
example.
I'd like to enable this if it doesn't make things too complicated.
> > Your first example indeed demonstrates why multiple profiles are useful
> > to be enabled at once.
> >
> > The second example can be accomplished with only one profile by marking
> > all dependencies that are not being needed by a "nocheck" profile as not
> > being needed by the "stage1" profile as well.
> >
> > So instead of:
> >
> > Build-Depends: foo <!stage1>, bar <!nocheck>
> >
> > and then needing two profiles at the same time, one could have:
> >
> > Build-Depends: foo <!stage1>, bar <!nocheck !stage1>
> >
> > Though I agree that the first option looks more maintainable.
>
> and I would assume that it better documents the intention. It maybe could be
> used for a (native) test rebuild on a slow architecture, where you wouldn't do
> that otherwise. For this case I don't want to have a package built with reduced
> functionality.
Makes sense.
> > There is also the idea of a "nodocs" profile which would work like
> > DEB_BUILD_OPTIONS=nodocs.
>
> This seems to be less important, because these b-d's most likely end up b-d-i.
There is potentially some overlap between DEB_BUILD_OPTIONS and
DEB_BUILD_PROFILES. Indeed implementing them as
DEB_BUILD_OPTIONS=profile=foo was in the spec at one point but we
moved away from that.
My feeling for the best way to think about this is that
DEB_BUILD_OPTIONS are for things that don't change the dependencies
(optimisation options, parallelisation options, most checks).
DEB_BUILD_PROFILES are for things that do have dependency
implications (bootstrap builds, embedded builds, check-only
build-deps, binaries not produced).
> Side question: if a package offers a --disable-docs configure option, is there a
> good way to enable it for arch only builds?
Shouldn't this be done in the rules file for binary-arch/binary-indep
targets?
> did somebody make an analysis for what stage1 and stage2 are currently used for?
Not a formal analysis, and having a done a few I suspect you have as
good an idea as anyone. I've found: Removing language bindings,
removing optinal library deps (selinux for eglibc for example, ldap
for gnupg or krb5), building without gui components when some fairly low-level
package also has a gui-tool that brings in a pile more build-deps.
> I would like to see more descriptive profiles, so I can break down these
> profiles ... For packages within a buildd chroot, I see
>
> - nobindings -- disabling bindings for various interpreters/languages.
> (could be something for DEB_BUILD_OPTIONS too, like nobindings=python,tcl)
>
> - no ... gobject-introspection, building udev without gobject-introspection
> and libgirepository1.0-dev.
>
> Even if there are a few more, I like it better to make the profiles more
> granular, and then letting the people doing a bootstrap decide what to include
> in a stage1 or stage2 build.
I can see some logic to this, and ultimately profiles _could_ be used
for anything like this. Packagers are best-placed to know which
aspects of their software are logically optional. But this could get
out of hand with a very long list in the build-deps line, so we should
resist going too crazy.
libdose can cope with an arbitrary set of profiles, and work out which
ones provide linearisable builds, so maybe there is no actual need for
regularised names (stage1, stage2), so long as available profiles are
discoverable (as ijw mentioned - I agree that would be wise).
I'm not sure how this might work with generating version numbers so
profiled builds supercede each other correctly in automated uploads
to a bootstrap repo. It's easy with 'stage1, stage2'. Tools would have
to get smarter with arbitrary names. But we can probably make it work
with a bit of thought. And it will work 'manually' without this (but
it's very annoying fighting reprepro all the time).
One thing that should come out of this work is recomendations for
packagers on what profiles are available/recommended/supported by
tools. We can use the mechansim as much/little as seems sensible.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: