Differences between revisions 58 and 59
Revision 58 as of 2014-08-29 10:00:21
Size: 11152
Editor: josch
Comment: updated libconfig-model-dpkg-perl
Revision 59 as of 2014-08-31 14:03:30
Size: 10338
Editor: josch
Comment: remove the namespace syntax
Deletions are marked like this. Additions are marked like this.
Line 31: Line 31:
This specification describes two possible extensions of the Build-Depends field
syntax. These extensions allow the marking of build dependencies as being needed
or not needed when a specific build profile is
activated. It also defines a new
field called "Build-Profiles" which aids in marking binary packages as being
built or not built whilst a certain build profile is
activated or having been
built with a certain set of
build profiles activated.
This specification describes an extension of the Build-Depends field syntax.
The extensions allow the marking of build dependencies as being needed or not
needed when one or more build profiles are
activated. It also defines a new
field called "Build-Profiles" which, depending on the context marks binary
packages as being built or not built with a certain set of build profiles
activated or marks binary packages as having been built with a certain set of
build profiles activated.
Line 52: Line 53:
Build-Depends: foo (>= 1.0) [i386 arm] <!profile.stage1> <!profile.cross>, bar Build-Depends: foo (>= 1.0) [i386 arm] <!stage1> <!cross>, bar
Line 63: Line 64:
Every term in a restriction list follows the following regular expression:

{{{
([a-z][a-z0-9-]*)\.([a-z][a-z0-9-]*)
}}}

The first group is called a namespace. The namespace `"profile"` is used to
support build profiles and is the only allowed namespace for now. By
introducing additional namespaces, this syntax can later be extended for other
uses besides build profiles (for example an `"arch"` namespace can be
introduced). The second group is called a label and specifies the profile name.

Terms can be negated by using an exclamation mark as a prefix just as
architectures in the architecture qualification list. In contrast to the
architecture qualification list, positive and negative terms are allowed to be
mixed.
Every term in a restriction list refers to the name of a build profile (see
above for a list). Terms can be negated by using an exclamation mark as a
prefix just as architectures in the architecture qualification list. In
contrast to the architecture qualification list, positive and negative terms
are allowed to be mixed.
Line 84: Line 74:
restriction lists within a restriction formula does not matter. In case of
build profiles, a "profile" prefixed term evaluates to "true" if the profile
was set for the build. It defaults to false if the profile was not set. In the
example above, the package would depend on `foo` for `i386` or `arm` and if
neither the profile `stage1` nor the profile `cross` are active.
restriction lists within a restriction formula does not matter. A term
evaluates to "true" if the profile with the same name was set for the build. It
defaults to false if the profile was not set. In the example above, the
package would depend on `foo` for `i386` or `arm` and if neither the profile
`stage1` nor the profile `cross` are active.
Line 93: Line 83:
Build-Depends: foo <profile.stage1 profile.cross> Build-Depends: foo <stage1 cross>
Line 102: Line 92:
Build-Depends: foo <profile.stage1 profile.cross> <profile.stage1> Build-Depends: foo <stage1 cross> <stage1>
Line 110: Line 100:
If a namespace is encountered that is unknown to the parser, then it is
interpreted as "false". So assuming the `foobar` namespace does not exist, the
following three statements are equivalent:


{{{
Build-Depends: foo <profile.stage1>
Build-Depends: foo <profile.stage1> <foobar.blub>
Build-Depends: foo <profile.stage1> <foobar.blub profile.stage1>
}}}
Line 124: Line 103:
field specifies the (unordered) list of build profiles for which that binary
package does or does not build. This list can either be all positive or all
negative. En
tries are negated by using an exclamation mark as a prefix.
field specifies the condition for which that binary package does or does not
build. To express that condition, the same restriction formula syntax from the
`Build-Depends` field i
s used.
Line 129: Line 108:
Build-Profiles: !cross !stage1 Build-Profiles: <!cross> <!stage1>
Line 134: Line 113:
profiles. profiles (including none at all).
Line 139: Line 118:
specifies the list of build profiles for which that binary or source package
was built.
specifies the white space separated list of build profiles with which that
binary or source package was built.

Document status

Preliminary support of this spec was implemented in

package

version

bug

vcs commit

dpkg

1.17.2

661538

git:7662e093 git:c87941de

sbuild

731798

apt

0.9.16.1

661537

git:565ded7b git:ce7f128c

python-apt

0.9.3.6

744243

git:c793c367

debhelper

9.20140227

git:f16d0915b

pbuilder

740577

lintian

2.5.22

740607

git:1f8821b8

dose3

3.1 (partial)

wanna-build

dak

744246

devscripts (mk-build-deps)

Uses libdpkg-perl so supports build profiles automatically

python-debian

libconfig-model-dpkg-perl

2.051

git:373cb3d0

augeas

haskell-debian

Problem description

For some compilation scenarios it is required to build-depend on a different set of binary packages than specified in the Build-Depends line. The two most important scenarios are:

  • Bootstrapping (for breaking build dependency cycles) and

  • Cross building (for source packages having different build dependencies during cross building than during native building)

This specification describes an extension of the Build-Depends field syntax. The extensions allow the marking of build dependencies as being needed or not needed when one or more build profiles are activated. It also defines a new field called "Build-Profiles" which, depending on the context marks binary packages as being built or not built with a certain set of build profiles activated or marks binary packages as having been built with a certain set of build profiles activated.

Build profiles can be activated by setting the environment variable DEB_BUILD_PROFILES or by using the -P option with dpkg-buildpackage (or -o Apt::Build-Profiles for apt, or --profiles in sbuild). More than one build profile can be activated at a time. Multiple profiles are specified by separating them with commas in commandline arguments and by separating them with spaces in the DEB_BUILD_PROFILES environment variable. The initial profile names are "stage1", "stage2", "nocheck", "nodoc", "nobiarch" and "cross".

Build-Depends syntax extension (restriction formulas)

An example demonstrating the restriction formula syntax for build profiles:

Build-Depends: foo (>= 1.0) [i386 arm] <!stage1> <!cross>, bar

This specification introduces a new pair of brackets (using < as the opening and > as the closing bracket) to be used after the architecture qualification list. The < and > brackets enclose a whitespace separated list of terms called a restriction list. But in contrast to architecture qualification there can be multiple < and > enclosed restriction lists. The list of restriction lists is called a restriction formula and individual restriction lists are separated by whitespace.

Every term in a restriction list refers to the name of a build profile (see above for a list). Terms can be negated by using an exclamation mark as a prefix just as architectures in the architecture qualification list. In contrast to the architecture qualification list, positive and negative terms are allowed to be mixed.

The terms arranged as a restriction formula form a disjunctive normal form expression. This is, each term within a restriction list is AND-ed together while the restriction lists in a restriction formula are OR-ed together. This also means that the order of terms within restriction lists and the order of restriction lists within a restriction formula does not matter. A term evaluates to "true" if the profile with the same name was set for the build. It defaults to false if the profile was not set. In the example above, the package would depend on foo for i386 or arm and if neither the profile stage1 nor the profile cross are active.

Second example:

Build-Depends: foo <stage1 cross>

In this case, the source package would build depend on foo only if both, the profile stage1 and cross are active.

Third example:

Build-Depends: foo <stage1 cross> <stage1>

In this case, the source package would build depend on foo if either both, stage1 and cross are active or if the profile stage1 is active. This means that the dependency is not applied if the profile cross alone is active.

The Build-Profiles field

In debian/control binary package stanzas, the content of the Build-Profiles field specifies the condition for which that binary package does or does not build. To express that condition, the same restriction formula syntax from the Build-Depends field is used.

Build-Profiles: <!cross> <!stage1>

If a binary package stanza in a debian/control file does not contain a Build-Profiles field, then it implicitly means that it builds with all build profiles (including none at all).

The Built-For-Profiles field

In *.changes and Packages files, the content of the Built-For-Profiles field specifies the white space separated list of build profiles with which that binary or source package was built.

The DEB_BUILD_PROFILES environment variable

The DEB_BUILD_PROFILES environment variable contains a space separated unordered list of activated profiles. The content of this variable must be honored by all tools involved in package compilation. Here an example for debian/rules (enabling sql for any build except stage1 profile - notice the negated test):

ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
    DH_OPTIONS += -Nlibdb5.1-sql # not needed with debhelper (>= 9.20140227)
    CONFIGURE_SWITCHES += --disable-sql
else
    CONFIGURE_SWITCHES += --enable-sql
endif

Profile built binary packages

A binary package must offer the exact same functionality for all profiles with which it builds including no activated profile at all (if it builds in that case). Otherwise a package depending on that binary package might not find the functionality it expects it to provide. This means that if necessary binary packages have to be split or that a source package has to be built in two stages. This requirement can not technically be checked before ReproducibleBuilds happen.

This requirement is does not apply if the "stage1" or "nodoc" profile is active. In this case, only the parts of the package that expose a functional interface (scripts, programs, libraries, headers) must not be different. Non-functional interfaces like documentation can be different or missing in the produced binary packages.

Example

Imagine src:foo depends on bar which is needed to build a plugin that is shipped together with other plugins in the package foo-plugins. When bar is made optional as a build dependency of src:foo in a stage1 build, then the resulting stage1 binary package foo-plugins would differ from the foo-plugins package that is created during a full build. Thus the creation of the foo-plugins binary package must be disabled by using the Build-Profiles field in the foo-plugins binary package stanza and by adding the necessary bits to debian/rules for packages without debhelper or when build depending on debhelper (>> 9.20140227) is not desired.

If foo-plugins has reverse dependencies which are part of a cycle with src:foo itself, then not building foo-plugins would not solve the bootstrap problem. In that case it is necessary to either:

  • split the foo-plugins package into foo-plugins-nobar and foo-plugins-bar and adjust *all* reverse dependencies of foo-plugins to correctly depend on foo-plugins-nobar and foo-plugins-bar

  • or create a package foo-plugins-nobar during a stage1 build and modify only the reverse dependencies that are in a cycle with src:foo to build depend on foo-plugins-nobar in their own stage1 build. When src:foo is built fully, it will not produce foo-plugins-nobar anymore but the full foo-plugins package instead.

Other uses for the restriction syntax

Mark build dependencies that need to be translated when cross building

See CrossTranslatableBuildDeps#A3._Use_restriction_syntax_with_new_namespace

Replace Build-Depends-Indep and Build-Depends-Arch

Instead of moving build dependencies needed to build arch:all or arch:any packages into Build-Depends-Indep and Build-Depends-Arch, respectively, mark them directly in the Build-Depends field using <debbuildopt.archindep> and <debbuildopt.archdep>, respectively.

Map DEB_BUILD_OPTIONS to namespaces

Some DEB_BUILD_OPTIONS like nocheck or noopt could be mapped to <debbuildopt.nocheck> or <debbuildopt.noopt>. This would allow not needing to install certain dependencies if certain DEB_BUILD_OPTIONS are active.

Discussion