On Fri 17 Nov 2023 at 14:07:54 (+0000), Tixy wrote: > 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...).
This is the bit I don't agree with. Perhaps just terminology… > > > > > 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'. Of course, the names of Debian packaged binary kernel images are an agglomeration of 'linux-image', flavour, upstream version, and a Debian version counter, incremented AIUI when the internal interfaces change (so that the modules will stay in step). > 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. And AIUI that version is the upstream source version, and a Debian counter for that source. The counter is rarely used, AFAICT, and can cause consternation when it is, because it means the kernel gets upgraded 'in place', making it tricky to revert if you wanted to. (That shouldn't normally be necessary.) And I'm sure you know all this, or something like it. > 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... > if↘ > $ 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. It is fuzzy in one sense. When APT and dpkg compare versions, they use the version numbers exposed in the name of the .deb file, which in your case above, are 6.1.55-1~bpo11+1 and 6.1.55-1: $ if dpkg --compare-versions 6.1.55-1~bpo11+1 gt 6.1.55-1; then echo True; else echo False; fi False $ This is caused by the use of ~bpo rather than -bpo, to make sure that backports get replaced, similar to the ~rc trick for release candidates. Otherwise you would get: $ if dpkg --compare-versions 6.1.55-1-bpo11+1 gt 6.1.55-1; then echo True; else echo False; fi True $ The 'fuzziness' is that your comparison is made using the /source/ version, which is why I included the Source field (src) in my listing. What I can't answer is why the top half of the list has their sources only specified as plain "linux". It's very easy to extract the source version from the package version, however (ie change the first - to +). But that question is moot, as it appears that reportbug may look on the internet, and could be doing something completely different anyway. Cheers, David.
