Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition
Package: debian-policy
Severity: normal
Hi,
the current use and definition of Build-Depends/Conflicts[-Indep] in
policy 7.6 don't match. Both use and definition also greatly reduce
the usefullness of these fields. This issue has come up again and
again over the last few years and nothing has been done about it. I
hope this proposal provides a elegant and non disruptive way out so we
can finaly do something about it.
Currently policy reads:
| 7.6 Relationships between source and binary packages -
| Build-Depends, Build-Depends-Indep, Build-Conflicts,
| Build-Conflicts-Indep
|
| Source packages that require certain binary packages to be installed
| or absent at the time of building the package can declare
| relationships to those binary packages.
|
| This is done using the Build-Depends, Build-Depends-Indep,
| Build-Conflicts and Build-Conflicts-Indep control file fields.
|
|Build-dependencies on "build-essential" binary packages can be
|omitted. Please see Package relationships, Section 4.2 for more
|information.
|
|The dependencies and conflicts they define must be satisfied (as
|defined earlier for binary packages) in order to invoke the targets in
|debian/rules, as follows:[42]
|
|Build-Depends, Build-Conflicts
|
| The Build-Depends and Build-Conflicts fields must be satisfied
| when any of the following targets is invoked: build, clean,
| binary, binary-arch, build-arch, build-indep and binary-indep.
This comes down to Build-Depends have to be always installed. Buildds
always and only install Build-Depends.
|Build-Depends-Indep, Build-Conflicts-Indep
|
| The Build-Depends-Indep and Build-Conflicts-Indep fields must be
| satisfied when any of the following targets is invoked: build,
| build-indep, binary and binary-indep.
But buildds do call the build targets (via dpkg-buildpackage) and
don't honor Build-Depends/Conflicts-Indep. And since build calls
build-indep that means anything needed to build the architecture
independent part needs to be included in Build-Depends. This make the
Build-Depends-Indep quite useless.
[Side note: Buildds/dpkg-buildpackage has no robust way of telling if
the optional build-arch field exists and must call build. This is
wastefull for both build dependencies and build time.]
Proposal:
---------
Two new fields are introduced:
Build-Depends-Arch, Build-Conflicts-Arch
The Build-Depends-Arch and Build-Conflicts-Arch fields must be
satisfied when any of the following targets is invoked:
build-arch, binary-arch.
The existance of either of the two makes build-arch mandatory.
The old fields change their meaning:
Build-Depends, Build-Conflicts
The Build-Depends and Build-Conflicts fields must be satisfied
when any target is invoked.
Build-Depends-Indep, Build-Conflicts-Indep
The Build-Depends-Indep and Build-Conflicts-Indep fields must be
satisfied when any of the following targets is invoked:
build-indep, binary-indep.
The existance of either of the two makes build-indep mandatory.
The use of Build-Depends/Conflicts-Arch/Indep is optional but should
be used in architecture "all/any" mixed packages. If any of them is
omitted the respective Build-Depends/Conflicts field must be suffient
already.
### End of Proposal ###
Why is this proposal better than others that have failed before?
- non disruptive: Current buildd behaviour will continue to build all
existing packages.
- Packages will not instantly have RC bugs.
- Simple to implement.
+ Trivial change in dpkg for the new field.
+ dpkg-checkbuilddeps has to parse 3 fields (2 with -B option)
instead of 2 (1).
+ sbuild, same change
+ Simple change for 'apt-get build-dep'
- Buildds/dpkg-buildpackage can use the build-arch target
+ reduces Build-Depends field and install time of same
+ build-indep is no longer called, reduces compile time and disk
space
- Build-Depends/Conflicts-Indep becomes usefull, build-indep becomes
usefull
Large packages no longer have to build indep stuff in the
binary-indep target to avoid building it on buildds.
MfG
Goswin
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.16-rc4-xen
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Reply to: