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

Re: consensus about Built-Using?

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

Reply to: