Re: Bootstrappable Debian - proposal of needed changes
Hi Johannes,
On Tue, Jan 15, 2013 at 07:18:40PM +0100, Johannes Schauer wrote:
[...]
> 2. Build-Profiles (extension 1)
> ===============================
>
> When a source package is built with fewer build dependencies (cross,
> embedded, stage1, nodocs...), then it often happens that it does not
> build one or more of its binary packages at all (e.g. foo-gtk, foo-java,
> foo-doc). While this is a minor nuisance during a half automated
> bootstrap, a fully automated bootstrapping process needs to know which
> binary packages a source package does not build if it is compiled in one
> of its profiles. We therefore propose a new field for binary packages in
> their control file which indicates for which profiles it builds.
>
> Builds-With-Profile: !stage1 !embedded
>
> Different profile names are separated by spaces similar to the
> Architecture field. A binary package with the above field would not be
> built during the profile builds "stage1" or "embedded". Binary packages
> which do not have this field would default to being built by every
> profile. This field would mean a minor change to dpkg-gencontrol.
>
>
> 3. Build-profiles (extension 2)
> ===============================
>
> A build profile is set either using a DEB_ environment variable or a
> command-line option. DEB_STAGE has been used historically in a few
> packages with staged build support, but that is specific to the
> staged-builds purpose. For the more generic build-profiles
> DEB_BUILD_PROFILE=<label> is proposed instead - (only 7 existing
> packages would need to be changed - patches exist for some already).
>
> Setting the build-profile causes dpkg-checkbuilddeps to use the modified
> deps, dpkg-gencontrol to mark the built package with a new field:
>
> Built-With-Profile: stage1 cross
>
> This new field is optional and just meant to mark binary packages such
> that they can not accidentally make it to the archive. Another idea is
> to encode this information in the package version by adding a ~stage1.
> Using the field is more powerful as source packages can also be built
> with multiple profiles activated at once and the field can store a list
> of profile names. In above example, the binary package was built with
> the cross profile activated for cross compilation and the stage1 profile
> activated to break a build dependency cycle.
>
> While this field is meant to make sure not to allow any profile built
> binary package to be uploaded to the archive, it can also be abused to
> only allow "some" build profiles to be uploaded.
If wanna-build is updated to support these two fields, then I imagine it
can run the bootstrapping dependency algorithm. While you wouldn't want
to upload a package to the debian.org archive when the architecture is
as yet incomplete, the same isn't true for the debian-ports.org archive.
It would require some patches for wanna-build to understand that package
"foo" would need to be rebuilt once a particular profile is fully built
and available, but I don't think that's impossible.
However, to do that, there's one thing I'm missing in your mail: there
will be cases where packages, when built in a particular profile do not
support some functionality. That is, the package is available and does
most of what the full package does, but because some build-dependency is
missing, it doesn't support some feature or other -- for example, let's
say that a document translation package (which we'll call "foo") which
supports many input formats does not support XML as an input format when
built in the stage1 profile. The output of its stage1 build would not
change the number of binary packages built with the source package, it
would just build a binary package with reduced functionality.
Now it might be that a package build-depends on our package foo because
it needs to translate documents in that XML format into something else,
With your proposal, there's no way for the build-depending package to
declare that it needs a version of foo that was built at a richer
profile than stage1.
Is this something you've considered?
--
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.
Reply to: