On 3/9/22 10:38, Ian Jackson wrote:
This prohibition exists solely because of a doctrinal objection to native-format packages with Debian revisions.
As I understood it, the idea was that you could just increment the "actual" version number. I'm failing to see the advantage of incrementing "a" vs "z" in something like x.y.z-a.
There's not really a disadvantage either, if it all works (which you said it does). But the doctrinal issue, I think, is that definitionally a native package has no Debian revision (corollary: a package with a Debian revision is non-native).
If we revise that definition, to allow Debian revisions in native packages, then what distinction is left between native and non-native packages?
Could we only have "3.0 (quilt)" then, no "3.0 (native)"? Or, put differently, if you had a "native" package that is using a Debian revision and we allow that, what difference is left between "3.0 (native)" and "3.0 (quilt)"?
To be clear: I genuinely don't know. I'm not implying that there isn't a remaining difference.
IMO there is nothing wrong with native format packages with Debian revisions. They work just fine. For a small paockage, this is often a good choice, because it avoids dealing with patches at all.
I don't follow the "avoid dealing with patches at all" piece here. -- Richard
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature