Hi Russ, On Tue, 2024-06-18 at 15:39 -0700, Russ Allbery wrote: > My understanding of the FTP team position is that the uploader must > generate and sign either the final source package, or the files that > constitute the unpacked view of the final source package, or a > trivial variation thereof, and include that signature in the upload. [...] > My understanding of the tag2upload developer position is that this > requirement prohibits the goal of tag2upload.ย People who want to > build the source package locally can already use the same algorithm > today; that's what dgit is.ย The whole point of the tag2upload > project is to remove the requirement that the package uploader > install dgit or equivalent software locally and build the source > package locally. This FTP team requirement therefore makes it > impossible for tag2upload to proceed; any system that would have the > required property would fail to accomplish the core goal of the > tag2upload project.ย Therefore, this delegate decision is blocking > the deployment of tag2upload.
The code the tag2upload developers wrote is perfectly able to do that: git-debpush, the tag2upload client by the tag2upload developers, doesn't require dgit nor building the source package, and documented in the initial mail about the GR to be used by people. It already looks at patched and unpatched source trees (and checks that patches applies) and compares them with the tree in Git. It could easily compute an integrity hash as well. Or is git-debpush itself incompatible with the goals of tag2upload? What would a client-side compatible with the goals then look like? Will such a client be available before the GR? I hope the tag2upload developers requirements will not make it impossible to proceed and they will not continue to block the deployment of tag2upload. Ansgar
