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 <emollier@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
Attachment:
signature.asc
Description: PGP signature