Re: consensus about Built-Using?
On 01/31/2013 23:41, Matthias Klose wrote:
> - The scope of what belongs into Built-Using is not clear. Policy is
> vague ("Examples include ...") and ftp-master seems to have a much
> more narrow interpretation.
There's an open bug[1] against debian-policy to improve the wording, but
nobody has suggested anything so far.
[1] <http://bugs.debian.org/688251>
> - policy 7.8 requires the "exactly equal" relation to express this
> dependency. This might be convenient for the dak developers, however
> it is not what you always want.
>
> - {gcj,gnat,gdc}-4.x do *only* use the upstream tarball in a
> gcc-4.x-source package, which doesn't change between full source
> uploads. So the correct field is e.g.:
> Built-Using: gcc-4.7 (>= 4.7.2), gcc-4.7 (<< 4.7.3)
For binary packages or Build-Depends using "=" causes problems as one
cannot install multiple versions in parallel.
Only allowing "=" for Built-Using makes the implementation in dak easier
(there's no real dependency handling in dak). We might keep a few
additional source packages in the archive, but I don't see a problem
with this.
> However I still fail to see, why the corresponding build-dependency
> cannot be used to extract this information.
We don't guarantee that build dependencies are always satisfied. The
source for a binary included in the archive should however always be
available.
> - Built-Using doesn't belong into the binary package. Now you add >100
> Built-Using attributes into the gcc-4.x control file just to replace
> everyone of these with the *source* package name. Nice! Granted,
> Ansgar Burchardt did provide me with a patch, but I won't do such
> exercises on my own. Why not as part of the changes file?
It's a property of the binary package that it incorporates stuff from
other packages, not a property of the upload.
We also don't keep changes files and exposing the Built-Using
information seems useful.
> - Built-Using shouldn't track source packages but binary packages.
Why?
> If the field is supposed to be used for license tracking, then you
> should consider that binary packages built from within the same
> source package have different licenses.
Different files in the same binary package can have different licenses
too. So one has to deal with this anyway.
Ansgar
Reply to: