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

consensus about Built-Using?

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.


Reply to: