Re: Recording VCS information in the source package info
On Tue, 16 Feb 2010 17:47:39 +0100, Raphael Hertzog <hertzog@debian.org> wrote:
> Hi James,
>
> On Tue, 16 Feb 2010, James Westby wrote:
> > I would therefore propose two new fields that would be optional in a
> > .dsc file, and possibly the Sources file, but not debian/control as they
> > are derived data. They would be:
> >
> > * Vcs-*-revision: A string meaningful to the Vcs that was used that
> > refers to the revision that the package was built from.
> >
> > * Vcs-*-tree: Some sort of hash of the tree contents that were built,
> > as it's possible that the contents were modified from the contents
> > of the revision that was checked out. This could either be a
> > Vcs-native thing, or some sort of abstracted hash, I'm not sure.
> >
> > I'm not sure what the best way to access this information when building
> > the package is, you would be able to state that better than me.
>
> Right now, dpkg-dev building tools are mostly VCS-agnostic (I would like
> this to change, by providing a generic vcs-buildpackage) and the only
> solution to add those fields is to pass -D parameters to the dpkg-source
> call.
Which isn't currently accessible from dpkg-buildpackage, advice on
dealing with that would be appreciated.
(vcs-buildpackage would be interesting, I'd contribute to that if you
start it)
> Thus supporting this currently means modifying
> svn-buildpackage/git-buildpackage/bzr-buildpackage, etc.
I'm the author of the latter, so that's one that will happily adapt.
> That said I like the principle of the idea.
Good.
> I'm not sure that VCS-*-tree is needed though, why not simply adding some
> sort of "dirty" marker in the VCS-*-revision field? What would the
> supplementary hash be useful for?
That's pretty much what it is doing at a first cut, but without having
to define a format for Vcs-*-revision beyond "string that means
something to the VCS."
It would allow tools to do more intelligent things sometimes though. A
tool may want to act differently if two packages with different revision
ids have matching trees.
Thanks,
James
Reply to: