On Tue, Aug 23, 2016 at 09:30:19AM -0400, Josh Triplett wrote:
> On Tue, Aug 23, 2016 at 01:59:13PM +0100, Ian Jackson wrote:
> > Josh Triplett writes ("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:
> > > > 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.
> > ...
> > > > I don't understand what your objection to this is.
> > >
> > > Lack of standardization and consistency.
> >
> > I think there should be a standard rules target for updating any
> > autogenerated debian/control. (And perhaps debian/copyright too...)
> > But the lack of a de jure standard does not mean that this approach is
> > not best practice.
>
> Agreed; I'd like to see best practice improved to standardize that
> procedure, though.
>
> > > 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).
> >
> > Please file bugs in such cases. If there are many, you may want to
> > make a MBF.
>
> I don't plan to look for such packages systematically, but if I run into
> one (typically through it breaking the build because I don't have
> whatever extra tools the control generator wants), I'll report it.
>
> > > 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,
> >
> > You should commit the generated debian/control to your version
> > control.
>
> Why? That would break the standard principle that version control
> should never contain a generated file, rather than the inputs that
> generate it. (Exactly the same reason "configure" doesn't belong in
> git, only "configure.ac".) I can run the generator, build the result,
> and upload it.
>
> (That would also imply not having debian/control as an input file, since
> the generation process also shouldn't modify any file checked into
> version control either.)
>
> For the same reason, version control wouldn't contain debian/copyright
> if that gets generated.
>
> (This also assumes the package has anything that needs to go in version
> control at all. If the unmodified output of the generator works as a
> source package, then it doesn't have anything to version. I'd only
> create a version control repository if it needed to contain a control
> template or other data to augment the output of the generator, such as
> if upstream doesn't have a sensible Description.)
This is exactly the point of debdry: you only keep in version control
what cannot be derived from the upstram metadata. It even supports
maintaining a partial debian/control that gets merged on top of the
autogenerated one.
It currently supports Python, Ruby, Perl, and Haskell, by calling the
respective packaging generators. Adding more languages is easy.
BTW debdry needs a new maintainer, and could really benefit from some
work to improve its workflow.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813203
Attachment:
signature.asc
Description: PGP signature