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? 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. My packages are patches-applied and I don't use debian/patches directly, so yes, *if* 3.0 (native) were a realistic option for uploading them, no transformation is currently required before uploading. 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. You would need to develop a replacement that worked with 3.0 (native) if you wanted to make this change in Debian. Lintian checks would misbehave, all sorts of downstream analysis code would likely get confused over whether my package was native rather than non-native, etc. We discussed the possibility that patches-applied packages could be represented as 3.0 (native), but we were (or at least I was) discussing that in a context where you, as FTP team delegate, deprecated 3.0 (quilt) for those packages and told everyone to use 3.0 (native) instead. That comes with a whole bunch of other obligations and work that you would have to do first. It is not something I could just do today. If you want to change source package formats, that's an interesting discussion and there are some theoretical advantages, but you have a long list of work ahead of you and problems to resolve before anyone else can reasonably take advantage of that change. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
