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) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]