4 ms·

> Debian testing already has a version called '5.6.1+really5.4.5-1' that is really an older version 5.4, repackaged with a newer version to convince apt that it

> Debian testing already has a version called '5.6.1+really5.4.5-1' that is really an older version 5.4, repackaged with a newer version to convince apt that it is in fact an upgrade. I'm surprised .deb doesn't have a better approach. RPM has epoch for this purpose http://novosial.org/rpm/epoch/index.html http://novosial.org/rpm/epoch/index.html

pja 3y ago
Debian packages can have epochs too. I’m not sure why the maintainers haven’t just bumped the epoch here. Maybe they’re expecting a 5.6.x release shortly that fixes all these issues & don’t want to add an epoch for a very short term packaging issue?
nicolas_17 3y ago
.deb has epochs too, but I think Debian developers avoid it where possible because 1:5.4.5 is interpreted as newer than anything without a colon, so it would break eg. packages that depend on liblzma >= 5.0, < 6. There may be more common cases that aren't coming to mind now.
- account42 3y ago
  Seems like debian is mixing too many things into the package version - version used for deciding on upgrades and abi version for dependencies should be decoupled like it is in modern RPM distros.
  - nicolas_17 3y ago
    If a binary library ABI is backwards-incompatible, they change the package name. I was just guessing at the reason epoch is avoided and that <6 is probably an awful example. So now I actually bothered to look it up, and it turns out the actual reason is that the epoch changes what version is considered "greater", but it's not part of the .deb filename, so you still can't reuse version numbers used in the past. If you release 5.0, then 5.1, then you want to rollback and release 1:5.0, it's going to break things in the Debian archives. https://www.debian.org/doc/debian-policy/ch-binary.html#uniqueness-of-version-numbers https://www.debian.org/doc/debian-policy/ch-binary.html#uniq... Additionally, once you add an epoch you're stuck with it forever, while if you use 5.1+really5.0, you can get rid of the kludge when 5.2 is out. https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly https://www.debian.org/doc/debian-policy/ch-controlfields.ht...
stefanor 3y ago
Debian has epochs, but it's a bad idea to use them for this purpose. Two reasons: 1. Once you bump the epoch, you have to use it forever. 2. The deb filename often doesn't contain the epoch (we use a colon which isn't valid on many filesystems), so an epoch-revert will give the same file name as pre-epoch, which breaks your repository. So, the current best practice is the +really+ thing.
- intel_brain 3y ago
  Got this on OpenSUSE: `5.6.1.revertto5.4-3.2`
- o11c 3y ago
  Honestly, the Gentoo-style global blacklist (package.mask) to force a downgrade is probably a better approach for cases like this. Epochs only make sense if your upstream is insane and does not follow a consistent numbering system.
  - account42 3y ago
    Gentoo also considers the repository (+overlays) to be the entire set of possible versions so simply removing the bad version will cause a downgrade, unlike debian and RPM systems where installing packages outside a repository is supported.
- kzrdude 3y ago
  Thanks for the info, the filename thing sounds like a problem, one aspect of the epoch system doesn't work for the purpose then.
- debianisajoke32 3y ago
  Stop the cap your honor. There is not a single filesystem that prevents you from using colons in filenames except exfat, I went ahead and checked and ext4, xfs, btrfs, zfs, and even reiserfs let you use any characters you want except \0 and /. And I fail to see why bumping the epoch would ever be a problem. Using the epoch not a reason why its bad.
5p4n911 3y ago
I really like the XBPS way of the reverts keyword in the package template that forces a downgrade from said software version. It's simple but works without any of the troubles RPM epochs have with resolving dependencies as it's just literally a way to tell xbps-install that "yeah, this is a lower version number in the repository but you should update anyway".

pja 3y ago

Debian packages can have epochs too. I’m not sure why the maintainers haven’t just bumped the epoch here. Maybe they’re expecting a 5.6.x release shortly that fixes all these issues & don’t want to add an epoch for a very short term packaging issue?

nicolas_17 3y ago

.deb has epochs too, but I think Debian developers avoid it where possible because 1:5.4.5 is interpreted as newer than anything without a colon, so it would break eg. packages that depend on liblzma >= 5.0, < 6. There may be more common cases that aren't coming to mind now.

account42 3y ago
Seems like debian is mixing too many things into the package version - version used for deciding on upgrades and abi version for dependencies should be decoupled like it is in modern RPM distros.
- nicolas_17 3y ago
  If a binary library ABI is backwards-incompatible, they change the package name. I was just guessing at the reason epoch is avoided and that <6 is probably an awful example. So now I actually bothered to look it up, and it turns out the actual reason is that the epoch changes what version is considered "greater", but it's not part of the .deb filename, so you still can't reuse version numbers used in the past. If you release 5.0, then 5.1, then you want to rollback and release 1:5.0, it's going to break things in the Debian archives. https://www.debian.org/doc/debian-policy/ch-binary.html#uniqueness-of-version-numbers https://www.debian.org/doc/debian-policy/ch-binary.html#uniq... Additionally, once you add an epoch you're stuck with it forever, while if you use 5.1+really5.0, you can get rid of the kludge when 5.2 is out. https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly https://www.debian.org/doc/debian-policy/ch-controlfields.ht...

stefanor 3y ago

Debian has epochs, but it's a bad idea to use them for this purpose. Two reasons: 1. Once you bump the epoch, you have to use it forever. 2. The deb filename often doesn't contain the epoch (we use a colon which isn't valid on many filesystems), so an epoch-revert will give the same file name as pre-epoch, which breaks your repository. So, the current best practice is the +really+ thing.

intel_brain 3y ago
Got this on OpenSUSE: `5.6.1.revertto5.4-3.2`
o11c 3y ago
Honestly, the Gentoo-style global blacklist (package.mask) to force a downgrade is probably a better approach for cases like this. Epochs only make sense if your upstream is insane and does not follow a consistent numbering system.
- account42 3y ago
  Gentoo also considers the repository (+overlays) to be the entire set of possible versions so simply removing the bad version will cause a downgrade, unlike debian and RPM systems where installing packages outside a repository is supported.
kzrdude 3y ago
Thanks for the info, the filename thing sounds like a problem, one aspect of the epoch system doesn't work for the purpose then.
debianisajoke32 3y ago
Stop the cap your honor. There is not a single filesystem that prevents you from using colons in filenames except exfat, I went ahead and checked and ext4, xfs, btrfs, zfs, and even reiserfs let you use any characters you want except \0 and /. And I fail to see why bumping the epoch would ever be a problem. Using the epoch not a reason why its bad.

5p4n911 3y ago

I really like the XBPS way of the reverts keyword in the package template that forces a downgrade from said software version. It's simple but works without any of the troubles RPM epochs have with resolving dependencies as it's just literally a way to tell xbps-install that "yeah, this is a lower version number in the repository but you should update anyway".