Hi, On Wed, 2024-06-19 at 08:26 +0200, Ansgar 🙀 wrote: > > 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.
And thinking about this a bit more: we have an existing resolution mechanism for this blocker. The technical committee could overrule the git-debpush maintainers to include such a hash. This would unblock deployment of tag2upload for Debian, including the continued use of integrity verification by the archive (in its current scope limited to mostly dak). Ansgar
