Re: Why is bullseye-backports recommended on bookworm?
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 <vincent@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.
> > > But I'm still wondering where reportbug gets this particular
> > > version 6.1.55+1~bpo11+1, as it is not in bullseye-backports.
> >
> > I just downloaded /debian/dists/bullseye-backports/main/binary-amd64/Packages.xz
> > (2023-11-02 13:59 395K), and it contains:
> [...]
>
> Note that for the Packages files, reportbug just uses the files from
> the /var/lib/apt/lists directory, but I don't have anything matching
> *bullseye* there.
I didn't know that, and at least one post in this thread suggests otherwise.
> > so there do appear to be 6.1.55-1~bpo11+1 candidates, like
> > linux-image-6.1.0-0.deb11.13-amd64-unsigned.
>
> Note the difference between 6.1.55-1~bpo11+1 and 6.1.55+1~bpo11+1
> (a "-" has been replaced by "+").
Yes, and I assumed that might be because sources are being looked up
as well as binaries. Looking at the list I posted, the top half has
the Sources (src) specified as plain "linux". The bottom half is more
forthcoming, with versions in parentheses. I can only assume that
these are source versions and that's the reason for their + signs.
But this is way deeper than I have plumbed in version numbering.
I used to compile custom kernels when the hardware was much simpler,
but my versioning was always protected by a nice big Epoch.
Cheers,
David.
Reply to: