Bug#1007717: Native source package format with non-native version
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
Reply to: