Hi, On 15/06/22 at 07:32 +0200, Helmut Grohne wrote: > The other model restricts itself to only adding files below > debian/ and then using debian/rules to actually apply patches during > build. This latter model is fairly annoying, because there are so many > different ways of doing it (i.e. we lack consistency there).
If you look at Debian 'testing' only, I think that the only remaining way to do that is 1.0 + quilt (packages that were using dpatch have all been converted or removed from testing). > So what I'd like to ensure is that any resolution we do here is clear > about discontinuing the use of 1.0-with-diff together with a patch > system to be applied during package build. We've explored that model in > depth and settled on 3.0 (quilt) as the superior solution. There is no > need to explore it any further (and as demonstrated by curl, gcc and > glibc, you can even turn 3.0 (quilt) ad absurdum). So in my view, the > only reasonable use of 1.0-with-diff is where you manage your diff > externally rather than during package build. According to https://udd.debian.org/~lucas/format10.cgi (which is based on what lintian knows about the archive), there are 114 packages using 1.0 with quilt. However, 67 of those are maintained by the Debian X team. If you plan to discontinue 1.0+patch-system in the context of this bug, it would probably be a good idea to have a discussion with them to better understand their use case. I personally think that it would be enough for this bug to issue a clear statement that we want to move away from 1.0 unless there's a good reason, on a per-package basis, not to. That would create a mandate to work on surveying the remaining packages and identifying the remaining use cases. That would also allow motivated volunteers to work on migrating the remaining packages when there's no reason to stay with 1.0, using the NMU procedure if needed. Lucas
