Re: Bootstrappable Debian - proposal of needed changes
Am 16.01.2013 17:26, schrieb Johannes Schauer:
> Hi,
>
> On Wed, Jan 16, 2013 at 04:00:15PM +0100, Matthias Klose wrote:
>> this only takes care about packages with a reduced package set built,
>> or packages with reduced functionality. There are same cases missing:
>>
>> - extra build dependencies for cross builds, like for gcc-4.7:
>> {gobjc++,gccgo,gfortran}-<target-gnu-type>
>> profile:cross?
>>
>> - build dependencies for running the check target. Usually these
>> dependencies can be ignored when cross-building packages, or when
>> building a package natively with DEB_BUILD_OPTIONS=nocheck.
>> profile:check? There are not few packages which can be easier
>> cross-built when identifying and dropping these build dependencies.
>>
>> So it does make sense to build with two profiles like stage1 & check.
>
> You probably mean a "nocheck" profile?
>
> 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.
> 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.
Side question: if a package offers a --disable-docs configure option, is there a
good way to enable it for arch only builds?
> An argument for them becoming build profiles is, that the analysis
> algorithm would then be able to just choose the less dangerous "nodocs"
> or "nocheck" profile instead of a "stage1" profile if they break a
> dependency cycle. How safe/dangerous choosing a profile is, could be
> evaluated by the number of binary packages which are not built with a
> given profile but which are needed as build dependencies by other source
> packages. While a "stage1" profile is likely to not build binary
> packages which are needed somewhere else, the "nodocs" and "nocheck"
> profiles will likely not lead to needed binary packages not being
> compiled.
>
> So "nocheck" and "nodocs" profiles could allow "safer" reduced builds.
did somebody make an analysis for what stage1 and stage2 are currently used for?
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.
Matthias
Reply to: