Control: severity -1 important Control: tag -1 confirmed I think I must elaborate on the below, because I believe it's a way bigger issue than it sounded like on first reading:
> If you are trying to keep up with
> the lastest/ stream of packages, I'm not sure I have a good
> solution at hand right now.
On regular packages, this should be a non-problem: the latest
package version would have the higher version number for sure.
However, there is a mismatch between upstream versionning, and
the versions caught by Debian packages. This originates from
the way uscan has been configured to catch ROCm versions and not
independent components versions (which are not exposed through
tags or releases, and thus not easy to use with common packaging
workflows).
At t time, the rocminfo package from ROCm 5.4.0 in upstream
repository for Ubuntu focal has version 1.0.0.50400-72~20.04.
Meanwhile in Debian bookworm, it has version 5.2.3-2, matching
an older ROCm 5.2.3 version. However, dpkg evaluates:
1.0.0.50400-72~20.04 < 5.2.3-2
This prevents installing later upstream versions when sticking
to the latest/ stream; this is true for most ROCm packages.
I'm not sure I see options which do not involve AMD updating
their .deb packages to include an epoch. By adding an epoch,
the upstream package would be greater than Debian's in any case
until we bump our own ourselfs (although one might rightfully
assume if someone want's AMD's, it is to not use Debian's):
5.2.3-2 < 1:1.0.0.50400-72
5.5.0-1 < 1:1.0.0.50400-72
This kind of situation has already existed in the past with
other repositories, and created great confusion from users
getting to move from packages of auxiliary repositories to
Debian ones, because of libraries mismatches.
On Debian side we could adjust watch files to catch the real
program version (not sure how though as these are not easy to
catch with uscan last time I checked), but we would still carry
around a versions higher than upstream's so their epoch would be
needed anyway:
1.0.0.50400-72~20.04 < 5.2.3+really1.0.0.50400-1
1.0.0.50400-72~20.04 < 1:1.0.0.50400-1
So in the long run we would have to both Debian and upstream
include epoch in the version number to both align on libraries
versions (or the L.M.N+reallyX.Y.Z thing until X.Y.Z ≥ L.M.N, at
least not forever like the epoch, nevertheless ugly).
It seems we're not very far from getting ourselves in one of the
very few cases of legitimate uses of epoch. :(
--
Étienne Mollier <emoll...@emlwks999.eu>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.
On air: Arena - The Heiligenstadt Legacy
signature.asc
Description: PGP signature
