Hi, On Fri, 2024-06-21 at 08:29 -0700, Russ Allbery wrote: > Ansgar 🙀 <ans...@43-1.org> writes: > > And you do not have a working tree containing either the patched source > > that would allow computing a integrity hash using 3.0 (native) or > > separate debian/patches where 3.0 (quilt) would work? > > Wait, why would I ever want to upload a 3.0 (native) package for a > non-native package with the tooling as it is today in Debian?
As far as I understand this whole thread is about changing the tooling. > If I did > that *today*, which I thought was the context of the question, that would > be a significant regression and I would lose functionality that I, and > other people downstream of me, rely on. > > But to take the > most obvious example, I rely on <https:/udd.debian.org/patches.cgi> to > communicate with upstream about exactly what changes I'm applying to their > code and allow them to easily pull those patches any time they want. Why do you point them to build artifacts instead of just the diff (including individual commits) between the upstream tree and Debian tree in Git? > You > would need to develop a replacement that worked with 3.0 (native) if you > wanted to make this change in Debian. There are already multiple such: salsa.debian.org and possibly dgit.debian.org to name two of them. I would still like to understand how your packages would not work with the suggested integrity check. Could you give an example, possibly with a reference to a Git repository as well? Ansgar
