On Thu, 18 Feb 2010 11:40:51 -0600, Jonathan Nieder <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
