On Thu, 2023-11-16 at 14:04 -0600, David Wright wrote: > On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent Lefevre wrote: > > On 2023-11-15 13:54:51 -0600, David Wright wrote: > > > On Wed 15 Nov 2023 at 20:01:20 (+0100), Vincent Lefevre wrote: > > > > On 2023-11-15 18:06:45 +0000, Tixy wrote: > > > > > On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote: > > > > > > On 2023-11-15 16:39:15 -0000, Curt wrote: > > > > > > > On 2023-11-14, Vincent Lefevre <vinc...@vinc17.net> wrote: > > > > > > > > > > > > > > > > The base number is the same, but I would have thought that this > > > > > > > > other > > > > > > > > kernel might have additional patches. > > > > > > > > > > > > > > > > > That's why I suggested ignoring the message. > > > > > > > > > > > > > > > > Then why does reportbug mention the bullseye-backports kernel? > > > > > > > > > > > > > > Because it kind of looks newer if you're a not very bright > > > > > > > software > > > > > > > construct, he opined. > > > > > > > > > > > > But the bookworm-backports kernel is even newer. > > > > > > So why not this one? > > > > > > > > > > Because it's a different package? > > > > > > > > There is no guarantee that a package with the same name in a > > > > different distribution has the same meaning (because packages > > > > get renamed...). So I would say that this is not a good reason. > > > > > > Well, it would seem strange to provide a backport for a package > > > and call it by a different name. But with kernels, there's always > > > the problem of a myriad of slightly different versions, so a > > > fuzzy name match might be appropriate. > > > > In any case, if a package is renamed (which particularly applies to > > unstable, I don't know about backports), I would expect reportbug > > to also consider the new name for a newer version of the package. > > In short, its search for newer versions should be based on the > > source package rather than the binary package. > > As I said above, I don't know whether they apply any fuzziness to the > version numbers in view of the multiplicity of linux-image versions > (and sources). As far as a 'rename' is concerned, I don't think that > linux-image has changed name since it was kernel-image in sarge.
There is no binary package called 'linux-image'. My PC has 'linux- image-amd64' installed which is a meta package who's description says 'This package depends on the latest Linux kernel and modules for use on PCs with AMD64'. At time of writing, that depended on package in stable is called 'linux-image-6.1.0-13-amd64' and the version of that package is '6.1.55-1'. This is the kernel installed on my machine. In the original post that sparked this thread, Vincent showed reportbug saying that same binary package (linux-image-6.1.0-13-amd64) had a newer version available in backports, with the version number 6.1.55+1~bpo11+1. Report bug is correct, that is a newer version by Debian versioning rules, there is no 'fuzzy' matching involved... $ dpkg --compare-versions 6.1.55+1~bpo11+1 gt 6.1.55-1; then echo True; else echo False; fi True Now, I admit, looking in a prior releases backports for a newer version seems wrong, assuming the machine in question didn't have that release in it's source.list. -- Tixy
