Hi,while I must admit that I was not at the latest IRC meeting where this topic came up, I am now bitten by this problem.
I maintain a bunch of kernel modules that can be either patched onto a kernel tree or built out-of-tree. No problem, have arch:all packages for patch and source and arch:any for the modules themselves. However, to build the kernel patch I need full kernel source, while kernel-headers is sufficient for the module builds.
Now what I'd like to do is to move kernel-source into Build-Depends-Indep, so the autobuilders don't need to install it. Wrong. Because the autobuilders invoke (via dpkg-buildpackage) the "build" target, which is supposed to build everything including the patch, I now need to have kernel sources around in order to generate a patch that is then thrown away.
There have been various proposals on that matter, and it always boils down to the same chicken-and-egg problem:
- policy documents existing practice, which is to invoke "build". - the existing practice cannot be changed because it would break packages- the policy cannot be changed because there needs to be an implementation first.
To summarize the proposals so far: - "Scan debian/rules, invoke build-arch if present". Has been tried, does not work.- "If a package has both Build-Depends and Build-Depends-Indep, it MUST have a build-arch target"
Would probably catch 95% of all cases. So far, I know no existing packages that don't have those targets but use both B-D and B-D-I. The drawback is that there are pretty ugly corner cases where you would have to jump through hoops to allow build-arch to be called (for example, if all the binaries you build can be built with just build-essential, but you need TeX for the documentation)
- "If a package has Build-Depends-Indep and is to be autobuilt, it MUST have a build-arch target"
This would be special treatment for the autobuilders. Would work in more cases than the check for both B-D and B-D-I though. As we cannot know before the build whether a package will build any arch-dependent packages, we can only guess here. To gain something here, we would have to check whether any binaries for other architectures already exist, and only in this case build-arch could be invoked. Talk about ugly.
- "Turn the SHOULD into a MUST in policy and have dpkg-buildpackage check the Standards-Version"
So far my favourite. It does not break any existing packages and can be easily implemented. The only drawback is that if your package doesn't need it and so you ignore the change, someone will NMU your package in order to bring it up to date with current standards. However the policy process gets in the way here: For this to work, we need a cutoff Standards-Version, and to have that, we need to be sure in which version of policy this will happen, however it is not going to become policy until we know it works (which is a good meta-policy IMO).
So my proposal to solve this would be:- create a policy revision that allows building a package with the "build-arch" and "build-indep" targets. However, the packages still need to build correctly when the "build" target is invoked, that is, their build-dependencies need to be complete for this target as well. This guarantees that we can pull out if anything goes wrong, as any packages that follow this standard will still build if we revert the change
- if no problems occur, allow build-dependencies that are strictly for build-indep / binary-indep only to be moved to Build-Depends-Indep. This will break building those packages with older dpkg-buildpackage unless care is taken to also install B-D-I, so I'd have no problem at all to postpone this step until after the etch release.
Questions? Comments? Seconds? Simon
Attachment:
signature.asc
Description: OpenPGP digital signature