Re: Bootstrappable Debian - proposal of needed changes
On 17/01/13 03:18, Wookey wrote:
> +++ Matthias Klose [2013-01-16 21:09 +0100]:
>> 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.
I feel as though the maintainers of individual packages probably know
better than the people who bootstrap architectures what can safely be
turned off on that package?
My interest in this work is that src:dbus needs a stage1 or otherwise
reduced profile which disables systemd support, and the subset of the
tests that use dbus-glib, breaking two separate circular
build-dependencies. (There's also a circular build-dependency on GLib,
but that'd be better broken from the GLib side, because it's only there
so GLib can run more tests.)
The resulting dbus package is "broken" from a normal-Debian point of
view, since it lacks functionality - namely systemd support - that the
normal package has; if something depended on dbus (>= nnn) expecting
that that would get it systemd support, that assumption would be broken
by the stage1 package.
At the moment I'm using comments in debian/control to tell bootstrappers
what they can safely drop, which seems to be the state of the art at the
moment.
> 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).
Depending what people use profiles for, is there a risk that a
bootstrapped build decides "hey this profile looks good, I'll use it"
and chooses one that's not really intended for that use? (Hypothetical
example: choosing the ubuntu profile in Debian because it has fewer
dependencies, with the side-effect that it enables extra patches that
only work when init is Upstart?)
> 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.
Turn 1.0-1 into 1.0-1~bootstrap20130117t1242, and avoid rebuilding a
package if that would "make it worse"? :-)
S
Reply to: