On Thu, Jan 31, 2013 at 11:41:40PM +0100, Matthias Klose wrote:
> Looking at recent package rejections for NEW uploads with the only thing being a
> missing Built-Using attribute, and the voluntary disclosures in the recent
> golang thread, I'm wondering if there is a consensus about the use of the
> Built-Using attribute. The current solutions looks rather simplistic, and don't
> offer much value (maybe except for easily implementing this in dak).
>
> - footnote 58 in policy 7.8 says "The archive software might reject
> packages that refer to non-existent sources". However they are also
> manually rejected. And it looks like others aren't aware of this too.
>
> - 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.
>
> If "linking with static libraries" (and "object files" is missing here)
> is what you want, then nearly every package having an executable
> should have a Built-Using: eglibc. Every binary or shared library
> linking with -lgcc (libgcc.a) should have a Built-Using: gcc-4.x.
> Same for clang and probably most other compilers.
> Is this wanted?
> What is the value having this?
The issue is licensing. These flags (IIRC) are to instruct the archive
to keep the source, so long as there's a package that was built using
it. Could be wrong, though.
This is a pretty important legal thing, IMHO. :)
>
> Looking further:
> - binaries copying config.{guess,sub}: Built-Using: autotools?
> - documentation copying templates: Built-Using: <doxygen|sphinx|...>
> - ...
>
> - 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)
> However I still fail to see, why the corresponding build-dependency
> cannot be used to extract this information.
>
> - libgcc.a doesn't change much, so what value does an exact version
> have? An interval spanning even major versions would be good
> enough to express this dependency. Otoh, how does a package uploader
> get this interval, instead of the exact version?
>
> - 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?
>
> - Built-Using shouldn't track source packages but binary packages.
> 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.
> E.g. a Built-Using linking against libiberty.a should have a
> different outcome than linking against the binutils libs (which
> nobody should do anyway, but this is a different story ...)
>
> As a first step, policy 7.8 should allow ranges instead of exact binary
> versions. And I would like ask ftp-master not to reject packages just on the
> basis of a missing Built-Using field. Please accept, and file a non-RC issue
> about this instead.
>
> Matthias
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 510AF324.5070506@debian.org">http://lists.debian.org/[🔎] 510AF324.5070506@debian.org
>
--
.''`. Paul Tagliamonte <paultag@debian.org>
: :' : Proud Debian Developer
`. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`- http://people.debian.org/~paultag
Attachment:
signature.asc
Description: Digital signature