Differences between revisions 5 and 6
Revision 5 as of 2013-08-27 11:52:26
Size: 4764
Editor: josch
Comment: do not allow mixing literals of different namespaces
Revision 6 as of 2013-08-27 12:20:19
Size: 4890
Editor: josch
Comment: profile -> build profile
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
We propose an extension of the Build-Depends field syntax. This extension allows to mark build dependencies as being needed or not needed when a specific profile is activated. We also propose the introduction of a new field called "Profile" which aids in marking binary packages as being built or not built while a certain profile is activated or having been built with a certain set of profiles activated. We propose an extension of the Build-Depends field syntax. This extension allows to mark build dependencies as being needed or not needed when a specific build profile is activated. We also propose the introduction of a new field called "Build-Profile" which aids in marking binary packages as being built or not built while a certain build profile is activated or having been built with a certain set of build profiles activated.
Line 10: Line 10:
Build profiles can be activated by setting the environment variable DEB_BUILD_PROFILE or by using the -P option with dpkg-buildpackage (or -o Apt::Build-Profile for apt). More than one profile can be activated at a time. Build profiles can be activated by setting the environment variable DEB_BUILD_PROFILE or by using the -P option with dpkg-buildpackage (or -o Apt::Build-Profile for apt). More than one build profile can be activated at a time.
Line 12: Line 12:
Binary packages which were built with one or more profiles activated will have these profiles appended to their version number. Binary packages which were built with one or more build profiles activated will have these profiles appended to their version number.
Line 22: Line 22:
Our proposal extends the architecture restriction syntax in square brackets from a single disjunctive list of architectures to a conjunctive list of logical disjunctions (a conjunctive normal form expression). Each clause of the conjunction is enclosed in square brackets. Every literal inside square brackets is a logical disjunction. The above example would therefore make the source package build depend on foo if the host architecture is either i386 or amd64 and if the profile named "stage1" is not active. Our proposal extends the architecture restriction syntax in square brackets from a single disjunctive list of architectures to a conjunctive list of logical disjunctions (a conjunctive normal form expression). Each clause of the conjunction is enclosed in square brackets. Every literal inside square brackets is a logical disjunction. The above example would therefore make the source package build depend on foo if the host architecture is either i386 or amd64 and if the build profile named "stage1" is not active.
Line 59: Line 59:
== The Profile field == == The Build-Profile field ==
Line 61: Line 61:
The meaning of the Profile field is similar (but orthogonal) to the Architecture field and also (just like the Architecture field) its meaning differs depending on where it is used. The meaning of the Build-Profile field is similar (but orthogonal) to the Architecture field and also (just like the Architecture field) its meaning differs depending on where it is used.
Line 65: Line 65:
Here, the content of the Profile field specifies the list of profiles for which that binary package does or does not build. This list can either be all positive or all negative. Entries are negated by using an exclamation mark as a prefix. Here, the content of the Build-Profile field specifies the list of build profiles for which that binary package does or does not build. This list can either be all positive or all negative. Entries are negated by using an exclamation mark as a prefix.
Line 68: Line 68:
Profile: !cross !stage1 Build-Profile: !cross !stage1
Line 71: Line 71:
If a binary package stanza in a debian/control file does not contain a Profile field, then it implicitly means that it builds with all build profiles. If a binary package stanza in a debian/control file does not contain a Build-Profile field, then it implicitly means that it builds with all build profiles.
Line 75: Line 75:
Here, the content of the Profile field specifies the list of profiles for which that binary or source package was built for. It is also possible to identify binary packages which were built with one or more profiles activated through their version number. Here, the content of the Build-Profile field specifies the list of build profiles for which that binary or source package was built for. It is also possible to identify binary packages which were built with one or more build profiles activated through their version number.
Line 79: Line 79:
Just as the Architecture field in a Sources file, the Profile field in a Sources file is automatically generated and specifies a list of profiles which that source package supports. It is therefore the union of the profile names given in the Build-Depends field and the profile names given in the Profile field in the binary package stanzas in the debian/control file. Just as the Architecture field in a Sources file, the Build-Profile field in a Sources file is automatically generated and specifies a list of build profiles which that source package supports. It is therefore the union of the build profile names given in the Build-Depends field and the build profile names given in the Build-Profile field in the binary package stanzas in the debian/control file.

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)

We propose an extension of the Build-Depends field syntax. This extension allows to mark build dependencies as being needed or not needed when a specific build profile is activated. We also propose the introduction of a new field called "Build-Profile" which aids in marking binary packages as being built or not built while a certain build profile is activated or having been built with a certain set of build profiles activated.

Build profiles can be activated by setting the environment variable DEB_BUILD_PROFILE or by using the -P option with dpkg-buildpackage (or -o Apt::Build-Profile for apt). More than one build profile can be activated at a time.

Binary packages which were built with one or more build profiles activated will have these profiles appended to their version number.

Build-Depends syntax extension

We propose a syntax which in practice looks as follows:

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

Our proposal extends the architecture restriction syntax in square brackets from a single disjunctive list of architectures to a conjunctive list of logical disjunctions (a conjunctive normal form expression). Each clause of the conjunction is enclosed in square brackets. Every literal inside square brackets is a logical disjunction. The above example would therefore make the source package build depend on foo if the host architecture is either i386 or amd64 and if the build profile named "stage1" is not active.

Every literal in a disjunction follows the following regular expression:

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

The first group is called a namespace and we propose the namespace "profile" to support build profiles. The second group is called a label and for the "profile" namespace we propose as initial labels "stage1", "stage2" and "cross".

The other already existing namespace would be "arch" for architectures. For backwards compatibility it is allowed to specify architecture labels without the "arch" namespace in front. The following is therefore equivalent:

Build-Depends: foo [i386 arm64]
Build-Depends: foo [arch.i385 arch.arm64]

These literals can be negated by using an exclamation mark as a prefix. We propose that literals inside a disjunction can individually be negated or not. To provide backwards compatibility, a disjunction which only contains architecture lables without the "arch" namespace must either be all negated or all positive. The following statements would therefore be legal:

Build-Depends: foo [profile.stage1 !profile.cross]

But the following would be illegal as it was before:

Build-Depends: foo [i386 !amd64]

We propose that literals of different namespaces cannot be mixed within a disjunction. Therefore, the following would be illegal:

Build-Depends foo [arch.i386 !profile.cross]

Should it ever be necessary, this restriction can easily be lifted at a later point.

The Build-Profile field

The meaning of the Build-Profile field is similar (but orthogonal) to the Architecture field and also (just like the Architecture field) its meaning differs depending on where it is used.

debian/control binary package stanza

Here, the content of the Build-Profile field specifies the list of build profiles for which that binary package does or does not build. This list can either be all positive or all negative. Entries are negated by using an exclamation mark as a prefix.

Build-Profile: !cross !stage1

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

*.changes and Packages file

Here, the content of the Build-Profile field specifies the list of build profiles for which that binary or source package was built for. It is also possible to identify binary packages which were built with one or more build profiles activated through their version number.

*.dsc file and Sources file

Just as the Architecture field in a Sources file, the Build-Profile field in a Sources file is automatically generated and specifies a list of build profiles which that source package supports. It is therefore the union of the build profile names given in the Build-Depends field and the build profile names given in the Build-Profile field in the binary package stanzas in the debian/control file.