publish debian package failing for official release

[diogomatsubara]

Describe the bug

Publishing the debian package for the 0.11.0 failed with the following error:

Error: `sudo apt-get install -y zenoh-plugin-storage-manager` failed with status code 100:
E: Failed to fetch file:/home/runner/work/zenoh/zenoh/0.11.0-rc.3/zenohd_0.11.0-rc.3_amd64.deb  File not found - /home/runner/work/zenoh/zenoh/0.11.0-rc.3/zenohd_0.11.0-rc.3_amd64.deb (2: No such file or directory)
E: Failed to fetch file:/home/runner/work/zenoh/zenoh/0.11.0-rc.3/zenoh-plugin-storage-manager_0.11.0-rc.3_amd64.deb  File not found - /home/runner/work/zenoh/zenoh/0.11.0-rc.3/zenoh-plugin-storage-manager_0.11.0-rc.3_amd64.deb (2: No such file or directory)
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

I believe this failed because we published 0.11.0-rc.3 debian packages and according to the Debian Policy Manual -- footnote 7 we should have used 0.11.0~rc.3 instead.

Another way to test this is to run on a debian box:

dpkg --compare-versions 0.11.0 lt 0.11.0-rc.3 && echo true
true
dpkg --compare-versions 0.11.0 lt 0.11.0~rc.3 && echo true

To reproduce

See https://github.com/eclipse-zenoh/zenoh/actions/runs/9364239510/job/25777234445

System info

• GH Runner

[diogomatsubara]

I discussed this issue with @fuzzypixelz and here are the 2 alternatives we thought out:

1. republish all the 0.11.0-rc* series using the DPM version recommendation with a tilde ~, so they will be 0.11.0~rc.3
2. fix the publishing to use the tilde ~ and then bump the patch version (0.11.1) so we can leave the 0.11.0-rc.3 behind

Option 1 has the potential of breaking the system for all our users and will require them to manually remove the old package 0.11.0-rc.3 and re-install the new package using the proper versioning scheme

Option 2 gives a clean upgrade path for users, but means we have to bump all of zenoh patch versions just for the debian package.

[fuzzypixelz]

I discussed this issue with @fuzzypixelz and here are the 2 alternatives we thought out:

1. republish all the `0.11.0-rc*` series using the DPM version recommendation with a tilde `~`, so they will be `0.11.0~rc.3`

2. bump the patch version (`0.11.1`) so we can leave the `0.11.0-rc.3` behind.

Option 1 has the potential of breaking the system for all our users and will require them to manually remove the old package 0.11.0-rc.3 and re-install the new package using the proper versioning scheme

Option 2 gives a clean upgrade path for users, but means we have to bump all of zenoh patch versions just for the debian package.

It's clear we need to change the Debian publishing action to let cargo-deb compute a version fitting the Debian Policy. The problem with this is that this version needs to be patched into the package.metadata.deb.depends fields and cargo-deb offers no way to to get this info ahead of time in the bump-crates action.

To salvage the current situation without breaking previously published packages, here are a few suggestions:

1. Publish 0.11.0 as 0.11.0+build.1 (or 0.11.0+electrode.1 or +exp.sha.d574654c6), abusing build metadata in semver. This compares later than 0.11.0-rc.3 because Debian considers rc.3 to be a revision and compares 0.11.0 and 0.11.0+<build-metadata> as upstream versions.
2. Publish 0.11.0 as 0.11.0-stable (the -stable suffix is used by Composer, a PHP dependency manager). This compares later than 0.11.0-rc.3 because the ASCII value of the letter "s" is greater than that of the letter "r".

I'm not in favor of publishing 0.11.1 as that implies a patch release throughout Eclipse Zenoh with no bugfixes.

[diogomatsubara]

Re-opening as the fix done in #175 didn't work for dev releases: https://github.com/eclipse-zenoh/zenoh/actions/runs/9556560003

Also in here: https://github.com/eclipse-zenoh/ci/blob/main/src/publish-crates-debian.ts#L70 we unpack the artifact to directory using the version. Should this be updated to the debian version as well?