Re: Computing Build-Depends at build time (and other updates to debian/control)?
Josh Triplett writes ("Re: Computing Build-Depends at build time (and other updates to debian/control)?"):
> Christoph Egger wrote:
> > Several packages create their control file from control.in during
> > maintainer build. You can have debian/control as a make dependency for
> > the package build target so it gets generated if it's not already
> > up-to-date. You just need to check it's correct and building on the
> > buildds does not generate a new/different controlfile.
>
> That last part seems like exactly the problem. If I can only run the
> process as part of a maintainer build, then I might as well just run the
> packaging tool and have it update the hardcoded Build-Depends in
> debian/control. I don't want the rebuild of debian/control to occur in
> advance and show up in the Debian diff; build and clean should never
> leave the package source changed. (For that matter, generated files
> shouldn't appear in version control.) Hence wanting to compute control
> (or just Build-Depends) at package build time, and define a subset
> Build-Depends for the tools needed for that computation.
You're effectively asking for the interface to a Debian source package
to be redefined so that every package must be built twice: once to
discover its control file, and then again to actually build the
binaries.
Just thinking about the amount of software that would have to be
updated should persuade you that this is a bad idea.
But even worse is that it would no longer be possible to sensibly
compute build orders without pre-building every package in a source
archive, because it would not be possible to statically determine
which binary packages are supposed to come from which sources.
Furthermore, once such a system was put in place, the
prebuild-dependencies would gradually grow.
All of this is a really bad direction to go in.
The right approach is the one we have now: we precompute this
information, and store and distribute it via the archive. When it is
necessary to update it, the maintainer can do so manually.
If you want to catch failures of the maintainer to do the update, you
can run your autogenerator in some kind of checking mode during
debian/rules. The result will be that your package FTBFS when the
control file is out of date. This is only a reasonable thing to do if
the control file depends only on other things in the same source
package.
If your control file depends on anything else, such a check would
probably be an inconvenience (or worse) to anyone trying to backport
your package, and might hinder security updates too.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: