Re: RFC declarative built-using field generation

[Andreas Beckmann <anbe@debian.org>]

On 2013-02-09 01:38, Russ Allbery wrote:
> Peter Samuelson <peter@p12n.org> writes:
>> I'm a bit confused.  Given that perhaps 99% of Built-Using would be for
>> trivial things like crt1.o and libgcc.a, which are concentrated into a
>> relatively tiny number of packages, it seems to make more sense to
>> annotate those packages - not unlike our shlibs files.
> 
> The proposal made in the Policy bug, which seems quite reasonable to me,
> is that we should only annotate packages with Built-Using if there are
> license implications to the inclusion of the source.

Without having read into this discussion in depth, the regular case when
Built-Using is needed seems to be as follows:
* there is a binary package foo-source that is intended to be used as
  "source" (either real source code or static libraries or stubs or
  ...) for building other packages and gets embedded (in some
  compiled binary form or another) into other binary packages
* it does not have a open use license for the parts getting embedded
  (so crt1.o and libgcc.a don't qualify for needing B-U)

Can't we just annotate the foo-source binary package in some way - it
should be pretty clear to the maintainer that he produces such a
"special" package. Then for building other packages B-D-ing on the
"special" package we could have a helper that looks for "annotated"
installed build-depends and generates Built-Using if needed.

That should be easier (especially if we can totally avoid manually
adding B-U: ${B-U} in packages using foo-source) than changing all
packages using foo-source.

If no binary package from src:bar has a B-U field in debian/control, it
should be automatically added to all binary packages (arch:all and
arch-dep) if the corresponding B-U substvar is not empty. But if any
binary package in debian/control has a B-U, this should be respected and
the other pakcages should be left alone. (e.g. if the B-U is only added
to arch:any packages but not to arch:all binNMUs may allow to get rid of
old B-U blocked packages from the archive by bumping the B-U versions.)

Maybe this will require splitting -dev packages with static libs into
-dev and -dev-static (or better drop the .a) to avoid having using the
-dev package for getting .h and .so imply a requirement for B-U.

Example:

Source: foo
...
Package: foo-source
X-Requires-Built-Using: yes
...

Source: bar
Build-Depends: foo-source
...
Package: bar
Built-Using: ${Built-Using}
...

Some helper (dh_built_using or whatever) could examine the installed B-D
(and B-D-I), look for X-Requires-Built-Using and populate a substvar as
needed.

We can have lintian checks about missing Built-Using if the package has
some B-D with X-Requires-Built-Using.


Another possible problem w.r.t. Built-Using: does the archive software
check the the B-U are satisfied at the time the package enters the
archive (a bin-nmu could be sufficient to fix this)?

Monday: NMU upload bar (2.3-4.5) built vs. foo (1.2-3) to DELAYED/10
Tuesday: security bug in foo, upload of foo (1.3-1) with urgency=high
Sunday: foo migrates to testing
Next Thursday: bar's delay is expired, but the foo that was used to
build it is now gone ...

(well, that can already happen in sid alone due to "bad timing" of
uploads of foo and bar w.r.t dinstall and mirror pushes)

Andreas