On Thu, 2013-02-07 at 15:09 -0400, Joey Hess wrote: > The Built-Using field required[1] 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. [...] > 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". [...] Or 'source', short for 'the build-dependency's source code should be treated as part of my source code'. This is already reserved as a special architecture name for use in changes file. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo.
Attachment:
signature.asc
Description: This is a digitally signed message part