[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

build, build-arch and build-indep targets in debian/rules



Hi,

in short (full rephrase below) I propose the following change to
debian-policy:

option 1: Make build-arch and build-indep targets mandatory in
          debian/rules

or

option 2: Add an optional "Build-Targets" line to debian/control.



Why?

While working on multibuild (a redesign/enhancement of the buildd
process) and building packages manually to help with the current lag I
noticed that there are some discrepancies between what policy and
common sence say and what is current practice.

So lets see how building packages works currently:

1) Install Build-Depends:
   - manual builds: 'apt-get build-dep <package>' installs
     Build-Depends and Build-Depends-Indep.
   -buildd builds: Only Build-Depends are installed

2) Build package with dpkg-buildpackage -B (called from debuild, sbuild,...)
   - make -f debian/rules build
   - make -f debian/rules binary-arch

As you can see manual builds and buildd builds differ in the amount
of packages they install. Policy says the following:

----------------------------------------------------------------------
| 7.6 Relationships between source and binary packages -
| Build-Depends, Build-Depends-Indep, Build-Conflicts,
| Build-Conflicts-Indep
|...
| 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.
| 
| 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.
----------------------------------------------------------------------

Buildds call the build target without supplying Build-Depends-Indep. A
fully policy compliant package should actually fail to build because
its Build-Depends-Indep are not fullfilled when calling build. Since
the package would FTBFS people have added packages to Build-Depends
that only need to be in Build-Depends-Indep.

Common practice is thus that only Build-Depends need to be fullfilled
when build is called (which could be changed over time if this
proposal succeeds).


The problem here is the buildd calling build, which also means a lot
of time is wasted on building arch indep files. It would be much nicer
if buildds would (could) call build-arch instead. Why don't they?

----------------------------------------------------------------------
| 4.8 Main building script: debian/rules
| 
| The targets are as follows (required unless stated otherwise):
| 
| build
|     The build target should perform all the configuration and
|     compilation of the package.
| ...
| build-arch (optional), build-indep (optional)
|     A package may also provide both of the targets build-arch and
|     build-indep. The build-arch target, if provided, should perform
|     all the configuration and compilation required for producing all
|     architecture-dependant binary packages (those packages for which
|     the body of the Architecture field in debian/control is not
|     all).
| ...
----------------------------------------------------------------------

The reason why "build-arch" is not used, if provided, is that it is
hard to properly detect if a debian/rules file has an build-arch
target or not. Aparently people have tried this and it has failed too
often. (One can't just make build-arch || make build since that would
build twice on FTBFS errors).

The intention of build-arch and build-indep (as well as Build-Depends
/ Build-Depends-Indep and binary-arch / binary-indep) clearly was to
avoid building arch indep files on the autobuilders thereby reducing
the buildtime of packages and overall lessen the burden (or lag during
upload frenzies like now). In that regard it has failed utterly.


My proposal is to make the build-arch and build-indep targets
mandatory in debian/rules so they can be utilised by dpkg-buildpackage
and through that by debuild, sbuild, pbuilder, uml-builder and
buildds. Packages that don't have a split build-arch and build-indep
target (yet) can use the following construct:

build-arch: build
build-indep: build

----------------------------------------------------------------------

Proposal option 1:
==================
Debian Policy 4.8 is replaced with the following rephrased text (lines
with + mark changed sentences):

| 4.8 Main building script: debian/rules
| 
| This file must be an executable makefile, and contains the
| package-specific recipes for compiling the package and building
| binary package(s) from the source.
| 
| It must start with the line #!/usr/bin/make -f, so that it can be
| invoked by saying its name rather than invoking make explicitly.
| 
| Since an interactive debian/rules script makes it impossible to
| auto-compile that package and also makes it hard for other people to
| reproduce the same binary package, all required targets MUST be
| non-interactive. At a minimum, required targets are the ones called
+ by dpkg-buildpackage, namely, clean, binary, binary-arch,
+ binary-indep, build, build-arch and build-indep. It also follows
| that any target that these targets depend on must also be
| non-interactive.
| 
| The targets are as follows (required unless stated otherwise):
| 
| build
|     The build target should perform all the configuration and
|     compilation of the package. If a package has an interactive
|     pre-build configuration routine, the Debianized source package
|     must either be built after this has taken place (so that the
|     binary package can be built without rerunning the configuration)
|     or the configuration routine modified to become
|     non-interactive. (The latter is preferable if there are
|     architecture-specific features detected by the configuration
|     routine.)
| 
|     For some packages, notably ones where the same source tree is
|     compiled in different ways to produce two binary packages, the
|     build target does not make much sense. For these packages it is
|     good enough to provide two (or more) targets (build-a and
|     build-b or whatever) for each of the ways of building the
|     package, and a build target that does nothing. The binary target
|     will have to build the package in each of the possible ways and
|     make the binary package out of each.
| 
|     The build target must not do anything that might require root
|     privilege.
| 
|     The build target may need to run the clean target first - see
|     below.
| 
|     When a package has a configuration and build routine which takes
|     a long time, or when the makefiles are poorly designed, or when
|     build needs to run clean first, it is a good idea to touch build
|     when the build process is complete. This will ensure that if
|     debian/rules build is run again it will not rebuild the whole
|     program.[21]
| 
| build-arch, build-indep
| 
+     A package must also provide both of the targets build-arch and
+     build-indep. The build-arch target should perform all the
+     configuration and compilation required for producing all
+     architecture-dependant binary packages (those packages for which
+     the body of the Architecture field in debian/control is not
+     all). Similarly, the build-indep target should perform all the
+     configuration and compilation required for producing all
+     architecture-independent binary packages (those packages for
+     which the body of the Architecture field in debian/control is
+     all). Likewise for build-indep. The build target should depend
+     on those of the targets build-arch and build-indep that are not
+     empty.
| 
+     Both the build-arch and build-indep targets must exist. If one
+     of them has nothing to do (which will always be the case if the
+     source generates only a single binary package, whether
+     architecture-dependent or not), it must still exist and must
+     always succeed.
| 
|     The build-arch and build-indep targets must not do anything that
|     might require root privilege.
| 
| binary, binary-arch, binary-indep
|     The binary target must be all that is necessary for the user to
|     build the binary package(s) produced from this source
|     package. It is split into two parts: binary-arch builds the
|     binary packages which are specific to a particular architecture,
|     and binary-indep builds those which are not.
| 
|     binary may be (and commonly is) a target with no commands which
|     simply depends on binary-arch and binary-indep.
| 
+     Both binary-* targets should depend on the appropriate
+     build-arch or build-indep target, so that the package is built
+     if it has not been already. It should then create the relevant
|     binary package(s), using dpkg-gencontrol to make their control
|     files and dpkg-deb to build them and place them in the parent of
|     the top level directory.
| 
|     Both the binary-arch and binary-indep targets must exist. If one
|     of them has nothing to do (which will always be the case if the
|     source generates only a single binary package, whether
|     architecture-dependent or not), it must still exist and must
|     always succeed.
| 
|     The binary targets must be invoked as root.[22] 
| 
| clean
| (continue as before)


Timeline:
=========
The proposal is not ment to take effect before sarge is out of the
way. Given the triviality of the change (adding two targets that
depend on build complies with policy) I would like to have this a
release goal for sarge+1.

It would be nice if the build-arch target would be required for all
new uploads so that autobuilders can take advantage of the target and
missing targets are found automatically. But this is not strictly
neccessary.

dpkg-buildpackages can check the "Standards-Version:" entry in
debian/control and, depending on the version, use the "build" or
"build-arch/indep" targets. That way backward compatibilty is
preserved.


----------------------------------------------------------------------

Proposal option 2:
==================
In Debian Policy 4.8 the explanation for 'build-arch (optional),
build-indep (optional)' is extended with the following:

|     A package providing one or both of the targets build-arch and
|     build-indep should add a "Build-Targets:" line in debian/control
|     listing the existing targets (see 5.6.22 Build-Targets).

Debian Policy 5.6.22 is added with the following text:

| 5.6.22 Build-Targets
| 
| A package providing one or both of the targets build-arch and
| build-indep should list possible targets in the "Build-Targets:"
| line.
|
| If a Build-Targets line exists it must list build-arch if any
| architecture-dependant binary packages (those packages for which the
| body of the Architecture field in debian/control is not all) are
| build from the source. Likewise it must list build-indep if any
| architecture-independant binary packages (those packages for which
| the body of the Architecture field in debian/control is all) are
| build from the source. All listed targets must exist in debian/rules
| and the binary-* targets must not depend on the build target.

Timeline
========
Again this is not ment to take effect before sarge is out of the
way. Given the simplicity of the changes I would like to have
Build-Targets a release goal for sarge+1 for all packages building
binary-arch and binary-all and a build time of over 10 hours on m68k.

The time limit could be adjusted or removed completly depending on how
well this takes hold.

dpkg-buildpackages can check for the "Build-Targets:" entry in
debian/control and, if provided, call the appropriate
"build-arch/indep" target (or fail if not listed). Otherwise the
"build" target is called. Backward compatibility is preserved.


Comments, ideas, opionion?

MfG
        Goswin



Reply to: