On 01/07/2024 20:48, Alec Leamas wrote:
Dear list,
Still working with the opencpn package. Now trying to normalize the
Ubuntu PPA builds so they can are based on the same debian/ directory
and tools as the existing Debian opencpn package.
opencpn is currently in a beta phase targeting a 5.10.1 release. The
beta versions are like "5.9.2-beta2+dfsg-1ubuntu1~bpo2204.1". The
upstream policy is to use 5.9.2-beta2, 5.9.3-beta3 so this ordering is, although a bit strange, still ok.
However, a quite large user base have PPA packages installed. These have versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build
number, so they are ordered. but all these versions are higher than anything like 5.9.x.
After some thought, I tend to think that adding an epoch is the right thing here.
The Policy [1] says:
---
Epochs can help when the upstream version numbering scheme changes, but they must be used with care. You should not change the epoch, even in experimental, without getting consensus on debian-devel first.
---
With all this said: Is this a case where using a epoch is justified? If not, why?
On 01/07/2024 21:51, Andrey Rakhmatullin wrote:
Hi Andrey.
Thanks for input.
On Mon, Jul 01, 2024 at 09:46:11PM +0200, Alec Leamas wrote:
After some thought, I tend to think that adding an epoch is the right
thing
here.
The Policy [1] says:
---
Epochs can help when the upstream version numbering scheme changes, but
they must be used with care. You should not change the epoch, even in
experimental, without getting consensus on debian-devel first.
---
With all this said: Is this a case where using a epoch is justified? If
not, why?
Adding epochs to work around 3rd-party repo version problems sounds quite wrong. We don't even add epochs that Ubuntu itself adds.
But this is not about third parties, it's about upstream which publishes
PPA packages. So far these are by far the most used Linux packages.
I also hesitate to add an epoch, after all they are basically considered evil. But if we should not use them when upstream has a broken
versioning we are about to replace, when should we use it?
I have good relations with upstream, and they are willing to abandon the current broken versioning in favor of something sane. But the legacy is there, and we need to handle it.
Have considered tricks like adding a 10000. prefix to the debian/ubuntu versions. But to me, this looks even worse.
Thoughts?
On 02/07/2024 00:10, Scott Kitterman wrote:
Hi Scott,
Upstream can change the versioning however they want. They are upstream. If
they don't care to fix it, then I think we assume they are fine with it and >> leave it as is.
But here the situation is that upstream do care and wants to fix it. But they need our help (an epoch) to accomplish this to handle the legacy.
We could be helpful, or not. Why not give a hand?
On 02/07/2024 00:31, Scott Kitterman wrote:wrote:
HI again
On July 1, 2024 10:18:07 PM UTC, Alec Leamas <leamas.alec@gmail.com>
8763.5.10But here the situation is that upstream do care and wants to fix it. But >> they need our help (an epoch) to accomplish this to handle the legacy.
We could be helpful, or not. Why not give a hand?
No. That's us fixing it. They can bump the version to whatever they want to address the issue. Epochs are forever, so should be a last resort.Yes, epochs are forever and should not be taken lightly, agreed.
Expanding on the situation. The current opencpn version is 5.9.x, soon
to be 5.10 in a tick-tock cycle.
However, the opencpn packages have versions like 8763.x, automatically generated from a build number. This is not communicated to users, they
just install and update.
Obviously, upstream should start building packages with versions like 5.9.x..., 5.10.x... etc. But any such version is lower than the current
build number.
If you switch hats for a moment: have you any advice for upstream in
this situation?
--alec
Hi againthe
On 02/07/2024 01:13, Scott Kitterman wrote:
On Monday, July 1, 2024 7:07:16 PM EDT Alec Leamas wrote:
On 02/07/2024 00:54, Scott Kitterman wrote:
On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
If you switch hats for a moment: have you any advice for upstream in >>>> this situation?
8763.5.10
Yes, I have had a similar idea using 10000 instead of 8763 to make it
stand out less. In my eyes, this is worse and will lead to that the
package versions does not match the "public" version like 5.10.2.
But if the list agrees that this is the correct solution so be it. To be >> honest, it might be a hard sell upstream.
Next build is:
8763.5.10~8764
Why?
--alec
Because the '~' means less than. It's a way to add the build number to
interim versions in the future without causing the same problem again. I guess it should have been 8763.5.11~8764, if 5.11 is the next 'real' version.
There is absolutely no need of build numbers in the version, it's just a
sad legacy.
Let's drop this subthread, keeping eyes on the ball: what is a sane version?
--a
On 02/07/2024 00:54, Scott Kitterman wrote:
On Monday, July 1, 2024 6:46:06 PM EDT Alec Leamas wrote:
If you switch hats for a moment: have you any advice for upstream in
this situation?
8763.5.10
Yes, I have had a similar idea using 10000 instead of 8763 to make it
stand out less. In my eyes, this is worse and will lead to that the
package versions does not match the "public" version like 5.10.2.
But if the list agrees that this is the correct solution so be it. To be honest, it might be a hard sell upstream.
Next build is:
8763.5.10~8764
Why?
--alec
On 02/07/2024 01:19, Alec Leamas wrote:
Let's drop this subthread, keeping eyes on the ball: what is a sane version?
Looking at this from another point of view: is there any situation where an epoch is appropriate?
On 02/07/2024 01:19, Alec Leamas wrote:
Let's drop this subthread, keeping eyes on the ball: what is a sane version?
Looking at this from another point of view: is there any situation where
an epoch is appropriate?
--alec
But this is not about third parties, it's about upstream which publishes PPA packages. So far these are by far the most used Linux packages.
I also hesitate to add an epoch, after all they are basically considered evil. But if we should not use them when upstream has a broken versioning we are about to replace, when should we use it?
1. Persuade users to uninstall PPA packages before installing official packages and also generation 2 PPA packages with sane versions like 5.10.x
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.
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.
For Debian users we backport opencpn which works well. However, the
Ubuntu backport process is, well, interesting (been there, done that).
The PPA represents a much better way to publish backports to current
Ubuntu branches. But for this to work we need to reset the versioning so
it works together with the official stream from Debian.
Anyway, seems we have a emerging conclusion that an epoch is a correct solution here.
On Monday, July 1, 2024 5:19:37 PM MST Alec Leamas wrote:
For Debian users we backport opencpn which works well. However, the
Ubuntu backport process is, well, interesting (been there, done that).
The PPA represents a much better way to publish backports to current
Ubuntu branches. But for this to work we need to reset the versioning so
it works together with the official stream from Debian.
Anyway, seems we have a emerging conclusion that an epoch is a correct
solution here.
That adds some needed clarification. I agree that in that circumstance, adding
an epoch is the best way forward. It allows you to maintain the current >upstream program version number, while unifying the Debian, Ubuntu, and PPA >version numbers in such a way that packages from those repositories can be >used interchangeably.
So have I also understood it.
And this is more or less the situation. For all practical purposes the
PPA is the current upstream packages, it's not some random packaging of opencpn. I have some control over both the PPA and the debian/ubuntu packages.
And what we want to do is to switch the upstream versioning in a way
which means the "next" version is lower than current version. The end
game is that the PPA is proper pre-releases of the official packages,
built from the same sources and debian/ directories.
On other words, a rather good example on when an epoch makes sense.
--alec
On 2024-07-01 23:59 +0200, Alec Leamas wrote:
But this is not about third parties, it's about upstream which publishes PPA
packages. So far these are by far the most used Linux packages.
I also hesitate to add an epoch, after all they are basically considered evil. But if we should not use them when upstream has a broken versioning we
are about to replace, when should we use it?
Quite. People are quite resistant to spoiling neat version numbers
with epochs, and no-one likes them, but they don't do any actual harm
(except sometimes break scripts and tools that forgot to allow for
them),
and this seems seems like a very sensible use case: essentially
jus thwat they are intended for.. Yes it was upstream that messed up
not us/you, but we have the technology and you can make user's lives
easier by just adding an epoch.
It's a pity upsream didn't know about the 0~ trick so that it wouldn't
matter what crazy version string was used, but it's done now.
After some thought, I tend to think that adding an epoch is the right thing
here.
The Policy [1] says:
---
Epochs can help when the upstream version numbering scheme changes, but they
must be used with care. You should not change the epoch, even in experimental, without getting consensus on debian-devel first.
---
With all this said: Is this a case where using a epoch is justified? If not,
why?
Adding epochs to work around 3rd-party repo version problems sounds quite wrong.
We don't even add epochs that Ubuntu itself adds.
But this is not about third parties, it's about upstream which publishes PPA packages.
I also hesitate to add an epoch, after all they are basically considered evil. But if we should not use them when upstream has a broken versioning we are about to replace, when should we use it?
I have good relations with upstream, and they are willing to abandon the current broken versioning in favor of something sane. But the legacy is there, and we need to handle it.
I would use an epoch.
Basically, you'd be burning a lot of social capital with upstream for no really good reason and you probably still wouldn't be able to convince
them. I don't think it's worth it.
I would just use the epoch. I know people really hate them and they have
a few weird and annoying properties, but we have a bunch of packages with epochs and it's mostly fine.
It's something you'll have to keep working
around forever, but not in a way that's really that hard to deal with,
IMO.
This feels like exactly the type of situation that epochs were designed
for: upstream was releasing packages with weird version numbers and now they're effectively going back to normal version numbers that are much smaller. In other words, to quote policy, "situations where the upstream version numbering scheme changes." Yes, in this case it was only in their packages and not in their software releases, but that still counts when
they have an existing user base that has those packages installed.
On Tue, 2024-07-02 at 00:54:13 +0100, Wookey wrote:
Quite. People are quite resistant to spoiling neat version numbers
with epochs, and no-one likes them, but they don't do any actual harm (except sometimes break scripts and tools that forgot to allow for
them),
Oh, but they can cause actual harm. As has been mentioned on this
list many times, epochs by design invalidate existing versioned
relationships in both packaging fields (inside the distro (but in this
case that does not look like a problem) and on custom local packages),
and on tools/(maint)scripts comparing these versions. These can either
cause letting versions that should not be installed through, or can
cause version unsatisfiability.
There's also the problem that epochs are (currently) not included as
part of the filenames.
They are also a common source of errors, due to people forgetting they
need to add them in relationships (if you read package changelogs,
this is a common-ish occurrence).
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.
opencpn is currently in a beta phase targeting a 5.10.1 release. The
beta versions are like "5.9.2-beta2+dfsg-1ubuntu1~bpo2204.1". The
upstream policy is to use 5.9.2-beta2, 5.9.3-beta3 so this ordering is, although a bit strange, still ok.
However, a quite large user base have PPA packages installed. These have versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build
number, so they are ordered. but all these versions are higher than
anything like 5.9.x.
anyhow here's my 2¢:
according to you¹, upstream have simply botched their package
versioning, which i would consider *a bug*.
bugs cause pain.
On 02/07/2024 20:46, Gunnar Wolf wrote:
Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]:
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.
You can also consider a third possible path: Pick a different package
name.
I am unfamiliar with opencpn to be able to suggest an alternative. But
given opencpn has never been part of Debian, you could just name your
package "opencpn-deb". Just to be sure users don't get surprised by
having two different versions of the same package, it can "Conflict:
opencpn". Then, you get a blank slate from which you can work your
versioning as you deem adequate.
It does, yes, introduce some confusion, but I think is the least evil
option.
opencpn is part of Debian since many years. However, the major
distribution is through an Ubuntu PPA, the official Debian package is
not that visible and of course outdated in Ubuntu.
opencpn users are counted in at least thousands. We are trying to
convince the developer community that it's a good idea to use a package created as an official Debian package rather than an auto-generated
cmake package distributed using the Ubuntu PPA.
IOhannes m zmölnig (Debian GNU|Linux) <umlaeute@debian.org> writes:
anyhow here's my 2¢:
according to you¹, upstream have simply botched their package
versioning, which i would consider *a bug*.
bugs cause pain.
AIUI the botching was done by whoever put the PPA together.
If that's the same as upstream, fair enough, but it seemed to me (having glanced at the repo) that upstream has been using sane versions
throughout.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 163:02:02 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,509 |