Re: Recording VCS information in the source package info
On Thu, 18 Feb 2010 11:40:51 -0600, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Okay, let me see if I understand:
>
> - The main user of this information would be the archive infrastructure;
> - The idea is to confirm that for each submitted binary package, the
> corresponding source is available;
We want to confirm that each source package is in the VCS. We don't want
the VCS getting out of date as someone forgot to commit, that's just a
pain.
> - For each binary package, this field identifies the corresponding
> source.
For each source package this field identifies the VCS tree/revision that
it was built from. This information can be useful in detecting that the
upload is in the VCS. (Not matching doesn't mean it isn't there, but
matching is a good indication that it is).
> Okay, makes sense. This is not convoluted at all, and I think the
> control file would be the right place for it.
Good.
> But especially because of this point:
>
> > However, often people will repeatedly test build their uncommited
> > changes, then when they are happy commit and upload the package that was
> > already built. In order that we can not be fooled by this we would want
> > the dirty flag. In order to notice that the revision that was pushed
> > differs to what was built but has the same contents then we want the
> > hash.
>
> What you are describing does not have as much to do with the Vcs-foo
> repository as I was imagining. What you need is a hash of the source
> tree used to build the package; the history is not at all relevant,
> and in fact you would want to ignore it. The main thing this has to
> do with version control systems is that each one has its own format
> for the hash of a file system tree, I guess.
Yes, I guess you are right. It could be an independent hash, but
allowing it to be VCS specific will usually be much more efficient when
checking.
I don't mind too much either way, the reason I suggested Vcs-*-tree was
that I came from Vcs-*-revision and realised tree information would be
useful too.
> With some existing packages, the full source in the form that gets
> uploaded is not actually in the source repository at all. For
> example, in a package I maintain, to build from a checkout you have to
> run debian/autogen.sh first to generate a debian/changelog.upstream
> file from the version control log.
>
> To work with archive infrastructure of the kind you describe, I would
> have to change my ways and check in the generated files, I guess.
Yes, you are correct. Some of this is things that are possible in the
system that we use, but not in every way you can use a VCS.
Thanks,
James
Reply to: