Soren et. al.,

On 02/07/2024 01:31, Soren Stoutner wrote:
Alec,


If upstream wants to fix this problem, they could just make their next release
version 9000, with the one after that either being 9001 or 9000.1.

Or, possibly, they could encourage everyone to uninstall the PPA package
before installing an official one.  For example, release a new package to their
PPA that displays a message encouraging everyone to uninstall the PPA package,
remove the PPA from their list of repositories, and *then* install the official
one.

As a general rule, I wouldn’t expect a user to keep a PPA package installed
when switching to an official package.  There is generally no guarantee that
upgrading from a PPA package to an official one will work without errors.

Or, once the official package had entered the system, they could instruct users
to remove the PPA from their list of repositories and then perform a
downgrade.

All of that being said, Debian could use an epoch to fix the problem.  Having
an epoch on a package isn’t the worst thing that has ever happened.

So, at least three possible paths:

1. Persuade users to uninstall PPA packages before installing official packages and also generation 2 PPA packages with sane versions like 5.10.x

2. Use versions like 9000.5.10, 9000.5.12. etc.

3. Use an epoch.

Of these I would say that 1. is a **very** hard sell upstream. Users are used to just update and will try, fail and cause friction.

2. and 3. both adds something which must be kept forever. Given this choice I tend to think that the epoch is the lesser evil, mostly because the package version could match the "real" version.

That is, the idea that next opencpn release officially would be 9000.5.10 just won't fly. 2. would be about using package versions with a number prefix like 9000. which is not really visible to users. And that means an impedance problem between the upstream version and the packaged one. A problem the epoch does not have.

--alec

Reply via email to