James Westby wrote: > On Tue, 16 Feb 2010 15:21:19 -0600, Jonathan Nieder <[email protected]> > wrote:
> > People could get the information you want by looking at the > > appropriate tag in the repository pointed to by Vcs-foo. > > Except that as I said, you don't know that the tag in Vcs-foo was what > was actually used to build the source package you have. 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; - For each binary package, this field identifies the corresponding source. Okay, makes sense. This is not convoluted at all, and I think the control file would be the right place for it. 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. 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. Thanks for the food for thought, Jonathan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
