Hi Russ, On Tue, Mar 15, 2022 at 09:22:09PM -0700, Russ Allbery wrote: > > Specifically, I'd like to ask the TC to come up with policy on native > > packages and debian revisions using its power under 6.1.1. > > As a Policy Editor, I support this request.
As a TC member I admit disliking this. While there is disagreement on how things are supposed to work, the views don't seem to be that far apart. Urgency is effectively removed by Lucas agreeing to pause further deprecation work. Do you think it would be impossible to move forward on this matter in a consensus-based way? > I've been involved in a lot of these discussions over the years, and the > tentative conclusion that I've come to is that we have unfortunately mixed > several different concepts in how we talk about source packages. This has > not *technically* reduced the flexibility of the packaging format because > there are various workarounds, but it's *conceptually* reduced the > flexibility in a way that makes those workarounds look conceptually > incorrect. As a result, we have constant repetitions of similar arguments > stemming from well-meaning attempts to clean up the apparent > inconsistencies (including some I have started). While I did point out the conflation of matters in my initial reply to Ian, I didn't put it as clearly as you did. Thank you. In the later replies to your mail, we see that even trying to disentangle this is difficult terminology-wise. > There are really two separate concepts in play here: I am wondering whether maybe one of you could work on a consensus seeking process about these matters. I believe that resolving this using consensus is far better than having 8 semi-random people decide upon a policy. The consensus-based approach does not seem impossible to me at this stage. > What I would propose is to separate these concepts cleanly so that we can > talk about them in a clearer way. We should define native and non-native > packages in terms of version numbers, and allow both native and non-native > packages to use single-tarball source package formats. We may want to > steer people away from using the single-tarball source package format for > the *normal* case of packaging upstream software, but I think it's well > within the sorts of trade-off decisions that packagers already make and > there are cases where a single tarball source format makes sense. Yes, please. Though as is evidenced in the replies to your mail, I would try to avoid "native" and "non-native" as much as possible given the existing confusion. I suggest using something like with-revision vs without-revision and single-tarball (from your mail) vs patches-separated to transport the concepts. Of course "3.0 (native)" as the content of debian/source/format cannot be avoided, but we can describe its current and possibly desired properties in a less confusing way. > The name of the 3.0 (native) source package format is unfortunate in this > context since it strongly implies that only native packages will use that > source format. The most formally correct thing to do would probably be to > introduce a new 3.0 (single-tarball) source format and use 1.0 until then, > but of course introducing a new source package format is not a fast > process. A more expedient thing to do may be to allow use of 3.0 (native) > with non-native packages, since it's identical to 3.0 (single-tarball) > except for the name, but it does leave a long-term confusing naming scheme > in place. Guillem may well have other and better suggestions from the > dpkg perspective; I haven't thought all that much about a transition plan. More and more, it seems to me that we are looking into design work as opposed to picking an existing option. I think it is preferable to do that with "normal" Debian processes without involving the TC, because the latter always comes with constitutional powers attached (used or unused). If history has taught us anything, involving the TC always comes with escalation. We may still reach a point where it is clear that consensus is not possible, but I don't think we're there yet. In the spirit of consensus: Do you agree that retrying this in a consensus-based way is still possible? Helmut