The Built-Using field required by recent policy results in some problems for maintainers: 1. It needs to indicate the exact version of the source package used in the build. So this has to be kept up-to-date, or dynamically generated. Updating it manually is busywork and won't reflect versions on the build daemons; dynamically generating it needs some messy scripting, especially in the case of packages that embed stuff from dozens of other packages, that may vary by architecture. 2. It violates DRY for many packages, since the build dependencies already contain similar lists of packages. But not close enough to the same to allow Built-Using to be automatically generated. So, I propose a backwards-compatable hack to the Build-Depends format that would allow creation of something like dh_buildusing, that can automatically populate a substvar for the Built-Using field. We can take advantage of the architecture specification in Build-Depends being fairly wide-open. So this should not break existing parsers: Build-Depends: foo [any built-using], bar [i386 amd64 built-using] Assuming there is never an architecture called "built-using", and that Build-Depends parsers never hardcode the list of all valid architectures (which would be prone to break them anyway), this seems an entirely safe thing to do. The only risk I can think of is that packages.debian.org would list the "built-using" in its display of build dependencies for source packages. With this info declared in the control file, a program can extract the marked build-depends that match the current architecture, map back to source packages, and generate the Built-Using field from them. It might be possible to use some special sigil, like "*" or "^" to mark built-using, but this seems less likely to work with all Build-Depends parsers. But if we wanted something shorter than "built-using", we could use "BU". Alternatively, a package named built-using could be uploaded. This would allow: Build-Depends: built-using, foo, built-using, bar [i386 amd64] Where the package following built-using is indicated as needing to go into Built-Using. This is 100% guaranteed to not cause any breakage (unless something is really stupid about duplicated package names in Build-Depends), but is IMHO uglier than the other option. -- see shy jo  Or at least encouraged, depending on how policy and the intent of policy is interpreted.
Description: Digital signature