dist: support smooth upgrade from enterprise to source availalbe #121
Conversation
When upgrading for example from `2024.1` to `2025.1` the package name is not identical casuing the upgrade command to fail. This makes packages upgradable from enterprise. Related scylladb/scylladb#22420 Signed-off-by: Takuya ASADA <syuu@scylladb.com>
|
did we had this one tested anywhere ? |
I assume we will test it as part of scylladb/scylladb#22420 |
| @@ -11,5 +11,14 @@ Architecture: any | |||
| Depends: %{product}-python3 (= ${binary:Version}) | |||
| Conflicts: cassandra | |||
| Description: cqlsh is a Python-based command-line client for running CQL commands on a cassandra cluster. | |||
| Replaces: scylla-tools (<< 5.2~rc0) | |||
| Breaks: scylla-tools (<< 5.2~rc0) | |||
| Replaces: scylla-tools (<< 5.2~rc0), scylla-enterprise-cqlsh (<< 2025.1.0~) | |||
There was a problem hiding this comment.
are we sure the ~ is enough to over all dev / rc versions ?
There was a problem hiding this comment.
Nope, but since @syuu1228 did it, let's wait for him to confirm
There was a problem hiding this comment.
(<< X.Y.Z~) is used on Debian wiki for example code,
https://wiki.debian.org/RenamingPackages
And the document says
https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-version-conventions
debian_revision
This part of the version number specifies the version of the Debian package based on the upstream version. It must contain only alphanumerics and the characters + . ~ (plus, full stop, tilde) and is compared in the same way as the upstream_version is.
Also we can compare version number by dpkg --compare-versions:
$ dpkg --compare-versions 2025.1.0~dev-0.20250126.48349d4d7c67-1 gt 2025.1.0~; echo $?
0
~$ dpkg --compare-versions 2025.1.0~rc0-0.20250126.48349d4d7c67-1 gt 2025.1.0~; echo $?
0
$ dpkg --compare-versions 2025.1.0~rc1-0.20250126.48349d4d7c67-1 gt 2025.1.0~; echo $?
0
$ dpkg --compare-versions 2025.1.0~rc2-0.20250126.48349d4d7c67-1 gt 2025.1.0~; echo $?
0
So I guess it is fine.
It only tested by manually for now. |
|
@fruch this part is working, i confirmed when testing it locally please merge this, i will update the submodule as part of my PR |
did we tried the RPM based ? |
no i will check it as well |
|
@fruch we need to backport this to 2025.1 to support the upgrades. Can you please create |
Isn't enough to backport the change to submodule ? |
|
@fruch yes, this is what we need to do, but the way to do it (or at least how things done in Scylla) is to create a branch and backport, |
it's a bit silly but there's now a new branch |
When upgrading for example from
2024.1to2025.1the package name is not identical casuing the upgrade command to fail.This makes packages upgradable from enterprise.
Related scylladb/scylladb#22420