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.