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

Bug#641153: document Built-Using field for binary packages



Hi,

Russ Allbery <rra@debian.org> writes:
> Ansgar Burchardt <ansgar@debian.org> writes:
>> A try at this:
>
>>   Some binary packages incorporate material derived from source
>>   or compiled code derived from other source packages.  In this case
>>   this field must be used to list all other source packages necessary
>>   to obtain the full corresponding source code.
>>   <footnote (or not?)>
>>     It indicates to the archive software to keep the listed source
>> packages around until the binary package disappears.
>>   </footnote>
>
> I think this is the right idea.  How about:
>
>     <p>
>       Some binary packages incorporate parts of other packages when built
>       but do not have to depend on those packages.  Examples include
>       linking with static libraries or incorporating source code from
>       another package during the build.  In this case, the source packages
>       of those other packages are a required part of the complete source
>       (the binary package is not reproducible without them), but there is
>       no other binary package control field to capture this relationship.
>       Build-Depends in the source package is not adequate since it
>       (rightfully) does not document the exact version used in the build.
>     </p>
>
>     <p>
>       Therefore, in cases like this where a part of another package is
>       incorporated into a binary package, the <tt>Build-Using</tt> field
>       must list the corresponding source package for any such binary
>       package incorporated during the build, including an "exactly equal"
>       ("=") version relation on the version that was used to build that
>       binary package.
>     </p>

Looks good to me.

> Why are we requiring source packages be listed in Build-Using instead of
> binary packages?  The archive software should be able to draw similar
> conclusions from a field listing the binary packages that were
> incorporated into the build, just by taking one additional step, and a
> field listing binary packages is *much* easier to generate.

I think source packages better reflect the meaning of the field (keep
the source available).  Listing them will hopefully soon no longer be
more complicated than binary package, see [1].

  [1] <http://bugs.debian.org/653575>

In addition listing binaries would likely force the archive software to
keep those specific binary versions around as well, even when they are
no longer needed, for example after a binNMU.  (At least I think the
current database layout would require this.)

Regards,
Ansgar



Reply to: