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

Re: Bootstrappable Debian - proposal of needed changes



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.

There is also the idea of a "nodocs" profile which would work like
DEB_BUILD_OPTIONS=nodocs.

Whether or not "nocheck" and "nodocs" can/should become build profiles
is of course still to be debated.

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.

An argument against "nodocs" might be, that since (most?) *-doc packages
are Architecture:all, the build dependencies that are needed by them to
be built are already/should be included in Build-Depends-Indep anyways.
The current algorithms discard the Build-Depends-Indep field as
Architecture:all binary packages do naturally not need to be built
during the bootstrapping process.

cheers, josch


Reply to: