Re: [RFC] General Resolution to deploy tag2upload
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
Reply to: