Re: Computing Build-Depends at build time (and other updates to debian/control)?
On Tue, Aug 23, 2016 at 11:45:03AM +0100, Ian Jackson wrote:
> Josh Triplett writes ("Re: Computing Build-Depends at build time (and other updates to debian/control)?"):
> > That describes the exact case that motivated me to raise this; the
> > uniform upstream packaging metadata used throughout the entire Cargo
> > ecosystem contains all the information needed to generate Build-Depends
> > (and Depends) on all other necessary Cargo packages. I'd like to avoid
> > repeating that information.
>
> As people have said: there is nothing wrong with writing a program to
> generate debian/control. You just need to 1. put the generated
> debian/control in the source package; 2. not have the Debian build
> system (ie, the normal rules targets) ever update it[1]; 3. rerun your
> generator manually whenever you like.
>
> [1] As I say, if the contents of debian/control only need to depend on
> other contents of the same source package, you can write a check to
> see whether it's up to date.
>
> I don't understand what your objection to this is.
Lack of standardization and consistency. I've seen various packages
implement this differently (and often not following point (2), insofar
as making a change to the package may cause the control generator to
re-run during clean or build). Even if dpkg-buildpackage doesn't invoke
this automatically, and the source package instead becomes a generated
output format not actually checked into version control, I'd still love
to see a consistent mechanism to invoke the control generator for any
package, and some (ideally enforceable) subset of Build-Depends needed
to run that generator.
If the generation doesn't run as part of the build process,
then perhaps this could just use a new build profile "control", tagging
the required Build-Depends with <control>, and a "debian/rules control"
target, not automatically invoked but manually invokable.
Reply to: