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

Re: RFC declarative built-using field generation

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 Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: