On 7/3/24 00:28, Alec Leamas wrote:
The upstream shall consider adopting 5 digit release version numbering
[...]
The upstream "shall" not do anything, they are open for discussions but certainly not for dictates.
thou shalt not ask if thou wisheth for no answers.(please keep in mind that not all Debian contributors are native speakers so you probably should go easy on the subtle differences between the various subjunctive forms. so unless somebody uses "SHALL (as in RFC-2119)", I would assume that the "shall" is a mere suggestion).
If you are able to sell this idea to upstream it would certainly work. I would not try it, it would generate a lot of friction to no use. And at
afaict, all suggestions end with that same argument: upstream would resist. which makes the discussion a bit moot.
anyhow here's my 2¢:according to you¹, upstream have simply botched their package versioning, which i would consider *a bug*.
bugs cause pain.if upstream acknowledges that it *is* a bug, they might be interested in fixing it (even if the fix causes more intermediate pain).
if they don't, I personally would go for a workaround like an epoch :-)and some other idea (not very well through through, it's still early in the morning and the caffeine level is low): depending on the ecosystem, you might get away with using an epoch only for the frontend application package. e.g. if there is a meta (binary) package "opencpn" that depends/recommends/... on various opencpn libraries, plugins and what not you could bump the epoch for this package only and have some clever Breaks against the too-high versions, which should eventually force the users to downgrade/re-install the child packages.
gdfasmr IOhannes¹ i looked up <https://launchpad.net/~opencpn/+archive/ubuntu/opencpn/+packages> and did not see any problematic package versions (i probably did not look long enough).
so which (actual) package/version is this about?
OpenPGP_0xB65019C47F7A36F8.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
