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?
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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/510af324.5070...@debian.org
