[Pkg-rust-maintainers] Computing Build-Depends at build time (and other updates to debian/control)?

[Josh Triplett]

[CCed to other potentially interested parties. Please CC me on replies.]

Mechanisms like shlibdeps, dh_perl, and other substvars allow packages
to compute their Depends at build time.  This avoids hard-coding
dependencies, simplifies upgrading the package to new versions, and
makes transitions much easier.

Some packages could potentially compute most of their Build-Depends the
same way.  For example, I'm working on a tool ("debcargo") to package
Rust libraries and applications, which include detailed metadata (via
Cargo) for dependencies on other Rust libraries.  Given a minimal set of
tools installed (cargo and that packaging tool), I could compute all the
necessary Depends and Build-Depends on Rust packages, including
versions.

Right now, that packaging tool has to compute the Build-Depends at
packaging time and embed them in debian/control.  (Most likely, I'll
include comments delimiting the Cargo dependencies, to make it easier to
update them.)

What would it take to compute Build-Depends at build time instead, with
a minimal set of Build-Depends installed to support doing so?

(This relates somewhat to build profiles, though not quite, as with
build profiles the Build-Depends field must still contain a list of
everything needed to build the package with no profile.)

This would clearly require a new version of dpkg-dev, to invoke a new
debian/rules target, and to enforce the computed Build-Depends.  Any
package using this feature would need to Build-Depends on a sufficient
version of dpkg-dev.  Package builders and other tools that install
Build-Depends (such as sbuild and pbuilder) would also need an update;
perhaps dpkg-dev could have versioned Breaks for tools that don't
understand this mechanism.  However, this shouldn't require waiting for
a new stable version of Debian before any package can use it; it would
only require waiting for a new dpkg-dev and updated autobuilder
infrastructure.

As one possible implementation, after dpkg-buildpackage checks that the
system satisfies the Build-Depends specified in debian/control, it could
check if the package specifies a specific flag header in the source
stanza of debian/control (for instance, "Build-Control: yes").  If
present, dpkg-buildpackage would back up debian/control and invoke
"debian/rules control", which should generate a new control file.
dpkg-buildpackage would then use that control file for the remainder of
the build process, starting by checking that the system satisfies the
new Build-Depends.  (The generation of the source package will include
the backed up debian/control file, not the generated one.)  (It might
also help to provide a helper program that merges two debian/control
files, so that "debian/rules control" can just produce the fields it
wants to update.)

This strawman proposal allows updating all of debian/control, not just
Build-Depends.  I've seen various requests over the years for the
ability to update debian/control at build time; it seems just as easy to
support that.  However, if that seems problematic for any reason, this
mechanism could instead just allow updating a subset of fields.

Any thoughts on this proposal?

- Josh Triplett