Joerg Jaspert <jo...@debian.org> writes: > Now, we have the following proposal on how to get t2u integrated. Note, > we are not entirely happy with it and do not think this is the best way > forward, but given the current situation, it is a way that gets things > untangled, and then we see what the future will bring.
Thank you very much for putting this together! I know how hard it is to coordinate a bunch of voices and turn them into something concrete. This is incredibly helpful and I really appreciate it. After reading this over and thinking about it for a bit, I had a few questions just to make sure I fully understood the proposal. > So, in short: A t2u uploaded source package should consist of whatever > t2u produces (normal Debian source package) *plus* two additional files. > The first file contains client side generated data, but to *not* > overburden the client, this *only* consists of the output of `git > ls-files --format="%(objectmode) %(objectname) %(path)"` for the tag > that should be uploaded, signed by the DD/DM key - or something > similarly easily generated on client side. Exact format can be hashed > out between t2u people and ftpmaster during implementation. You describe the contents here, but not the semantics, and I'm not sure that I fully understand what the intended semantics are (in other words, what packages dak will accept under this proposal). Would source packages that contain additional files not represented in this list of files and hashes be accepted, for example? Here's one specific concrete example for one workflow using tag2upload (there are other variations): suppose I, as the uploader, tag a Git tree that is patches-applied with no patches in debian/patches/*. I run the above command and include that signed data somewhere where tag2upload can get at it via the Git tag. tag2upload then turns that into a 3.0 (quilt) package and uploads that package along with the information as requested, including that list of files and hashes that I signed from the tree that I tagged. When dak sees the package, all of the files in debian/* in the source package will have the same hashes as in the git ls-files output, but the source package will have additional files in debian/patches/* that do not exist in the git ls-files output. Some of the upstream files will have hashes in the git ls-files output that match the contents of those files after unpacking the source package (and thus applying patches), but will not match the hashes of those files as they exist in the upstream orig.tar.gz. In this proposal, would dak be willing to accept such a package? There are a few other, similar sorts of cases. Perhaps the other that's the most interesting is the case where tag2upload has to build the orig.tar.gz file because this is a new upstream release. The contents of that tarball will be identical to the Git tree referenced by the upstream hash in the signed Git tag. Ignoring, for now, the case of a repository that contains only the debian/* files, the file hashes in the git ls-files output will *either* match the file hashes in the orig.tar.gz file *or* the file hashes of the corresponding unpacked source package, but those two hashes may be different for specific upstream files that are patched by Debian. The case of a repository that contains only the debian/* files poses another set of complications, but I don't think we have to get into that immediately. The above examples are probably enough to work through to understand what the intended semantics of this manifest is. > The second file consists of a shallow git clone of the repository for > the tag that t2u wants to upload, put into an appropriately named > tarball. Just to double check, to make sure I'm not missing some subtlety, it's intentional that this file contains all of the same information as in the first file, and the first file is just a subset of this same information in a different form? In other words, someone could verify the signature on the Git tag in this file and then run the git ls-files command on the Git repository and get exactly the same information as in the first file, so the first file is technically redundant. I can think of some reasons why you might want that, but it's a little surprising, so I wanted to make sure that's intentional. > Obvious (ha) note: The above mentions a command and stuff, but the exact > way is up to implementation. It can even contain more data if deemed > useful or add a file from t2u with a list what it added/generated, for > example. Or - in the future - might be completely replaced with another > implementation we all agree on, provided it has similar minimal basic > requirements as the thing proposed here. (Summarized as detached > signature from the DD/DM over the tree of the tag, and that tree/tags > data available in a file beside the upload). Oh, yeah, for sure, none of the details now should block future improvements worked out in the normal way. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
