2940
Comment: initial version
|
5077
explain the (common!) negated check, instead of (double-mix and at not less confusing) anti-negation by counting sorted filter
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
== Document status == Preliminary support of this spec was implemented in dpkg 1.17.2. A patch for sbuild exists: DebianBug:731798 |
|
Line 3: | Line 8: |
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: | 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: |
Line 8: | Line 15: |
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. | 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. 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", "notest" and "cross". Other possibilities are "nodoc" or "embedded". Binary packages which were built with one or more build profiles activated will have these profiles appended to their version number. |
Line 12: | Line 36: |
We propose a syntax which in practice looks as follows: | An example demonstrating the build profile syntax: |
Line 15: | Line 39: |
Build-Depends: foo (>= 1.0) [i386 arm] [!profile.stage1], bar | Build-Depends: foo (>= 1.0) [i386 arm] <!profile.stage1 !profile.cross>, bar |
Line 18: | Line 42: |
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. | 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. Just as in the architecture qualification list, the literals within the <> brackets form a disjunction. |
Line 23: | Line 50: |
([a-z][a-z0-9]*)\.([a-z][a-z0-9]*) | ([a-z][a-z0-9-]*)\.([a-z][a-z0-9-]*) |
Line 26: | Line 53: |
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 first group is called a namespace and the namespace "profile" is used to support build profiles. The second group is called a label and specifies the profile name. |
Line 28: | Line 57: |
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: | These literals can be negated by using an exclamation mark as a prefix. Just as in architecture qualifications, either all literals must be positive or all must be negative. No other namespaces besides "profile" exist yet but it is forbidden to mix different namespaces within one disjunction. === Future extensions === * It could be allowed to mix positive and negative literals in one <> block but the implications when multiple profiles are enabled is potentially confusing * The syntax could be extended to allow more than one <> block, forming a conjunctive normal form expression * It could also be allowed to allow architecture names under the "arch" namespace within a <> block. * It could be allowed to mix different namespaces within a <> block == The Build-Profiles field == In debian/control binary package stanzas, the content of the Build-Profiles 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 31: | Line 79: |
Build-Depends: foo [i386 arm64] Build-Depends: foo [arch.i385 arch.arm64] |
Build-Profiles: !cross !stage1 |
Line 35: | Line 82: |
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 their "arch" namespace must either be all negated or all positive. The following statements would therefore be legal: | 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. In .dsc file and Sources files, the Build-Profiles field 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 in the debian/control file and the build profile names given in the Build-Profiles field in the binary package stanzas in the debian/control file. == The Built-For-Profiles field == In *.changes and Packages files, the content of the Built-For-Profiles 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. == The DEB_BUILD_PROFILES environment variable == The DEB_BUILD_PROFILES environment variable contains a space separated 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): |
Line 38: | Line 108: |
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 can be mixed within a disjunction. Therefore, the following would be legal: {{{ Build-Depends foo [arch.i386 !profile.cross] |
ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),) DH_OPTIONS += -Nlibdb5.1-sql CONFIGURE_SWITCHES += --disable-sql else CONFIGURE_SWITCHES += --enable-sql endif |
Line 53: | Line 116: |
== The Profile field == | == Discussion == |
Document status
Preliminary support of this spec was implemented in dpkg 1.17.2. A patch for sbuild exists: 731798
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 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.
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", "notest" and "cross". Other possibilities are "nodoc" or "embedded".
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
An example demonstrating the build profile syntax:
Build-Depends: foo (>= 1.0) [i386 arm] <!profile.stage1 !profile.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. Just as in the architecture qualification list, the literals within the <> brackets form a disjunction.
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 the namespace "profile" is used to support build profiles. The second group is called a label and specifies the profile name.
These literals can be negated by using an exclamation mark as a prefix. Just as in architecture qualifications, either all literals must be positive or all must be negative.
No other namespaces besides "profile" exist yet but it is forbidden to mix different namespaces within one disjunction.
Future extensions
It could be allowed to mix positive and negative literals in one <> block but the implications when multiple profiles are enabled is potentially confusing
The syntax could be extended to allow more than one <> block, forming a conjunctive normal form expression
It could also be allowed to allow architecture names under the "arch" namespace within a <> block.
It could be allowed to mix different namespaces within a <> block
The Build-Profiles field
In debian/control binary package stanzas, the content of the Build-Profiles 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-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.
In .dsc file and Sources files, the Build-Profiles field 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 in the debian/control file and the build profile names given in the Build-Profiles field in the binary package stanzas in the debian/control file.
The Built-For-Profiles field
In *.changes and Packages files, the content of the Built-For-Profiles 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.
The DEB_BUILD_PROFILES environment variable
The DEB_BUILD_PROFILES environment variable contains a space separated 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 CONFIGURE_SWITCHES += --disable-sql else CONFIGURE_SWITCHES += --enable-sql endif