(There's a suggestion of a possible answer for the OP to check out, down
at the bottom of this message.)
On 2021-03-22 at 07:49, Andrei POPESCU wrote:
> On Lu, 22 mar 21, 07:26:27, The Wanderer wrote:
>
>> On 2021-03-22 at 07:22, Andrei POPESCU wrote:
>>
>>> In any case, backports is, by definition, lagging behind
>>> testing.
>>
>> Yes, but that should only be reflected in the fact that the
>> package version is different, not in which packages are available
>> (barring the case where the newer version changed which packages
>> get built, which doesn't apply here).
>
> Except that the package name in backports is different, i.e. the
> package is rebuilt for backports (in a stable build environment) and
> it also has its name changed.
Yes, because the version is different, and (for kernels) some aspect of
the version is encoded in the package name. I consider that to fall
under the package version being different.
>> Note that I checked the stable-backports listing for the version
>> specified in the OP, and the testing listing for the version shown
>> on my system as available in testing.
>>
>> If that's not the root of your point, then I'm missing it, and
>> would be glad to see it explained.
>
> My point is that whatever is (already) in testing provides little
> clue for what should be in backports, especially for linux-image
> packages that have the signing step in addition to a rebuild with
> changing the package name. Besides, only some linux-image versions in
> testing will get a backports upload.
I still don't think I see your point - or else I entirely disagree with
it.
I was not, and am not, expecting the version in backports to be the same
as the version in testing - and indeed, it isn't. Versions are
irrelevant to what I'm looking at, and looking for.
I was, and am, expecting that the package *variants* in backports (in
terms of architectures, debug symbols, signing, ...) will be the same as
the variants in testing, barring changes in packaging which would affect
which packages get generated, and barring differences in which
architectures are considered supported enough to get package builds -
and indeed, at a glance the set of variants in testing and the set of
variants in backports seem to match exactly.
And when I looked, neither of the variant sets in question seemed to
include the plain '-amd64' package name, although they did include the
'-amd64-unsigned' package name, and both variants of the package are
present in testing (for the kernel version which is in testing, which is
obviously distinct from the one which is in backports).
Let me try going over it again. Here's what my system sees as being
available in testing:
$ apt-cache policy linux-image-5.10.0-4-amd64{,-unsigned}
linux-image-5.10.0-4-amd64:
Installed: 5.10.19-1
Candidate: 5.10.19-1
Version table:
*** 5.10.19-1 900
900 http://ftp.us.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
linux-image-5.10.0-4-amd64-unsigned:
Installed: (none)
Candidate: 5.10.19-1
Version table:
5.10.19-1 900
900 http://ftp.us.debian.org/debian testing/main amd64 Packages
If I search https://packages.debian.org/source/testing/linux for those
package names, I find linux-image-5.10.0-4-amd64-unsigned, but I do not
find linux-image-5.10.0-4-amd64 itself - even though apt reports that it
is, in fact, present.
This mismatch between what packages are listed on that page and what
packages are actually in the repository is clearly a discrepancy, and is
the core of what I am focusing on in my comments here to date.
Because of the existence of that discrepancy, I am inferring that the
fact that we do not see linux-image-5.10.0-0.bpo.3-amd64 (or, for that
matter, linux-image-5.10.0-0.bpo.4-amd64) on
https://packages.debian.org/source/stable-backports/linux may only
reflect a similar discrepancy, and thus may not be enough to let us
conclude that that package is not available in that repository.
Does that explain what I'm getting at a little bit better?
At the same time, investigating to provide that second attempt at the
explanation may have led me to discover a possible angle to the original
question.
@OP: Is linux-image-5.10.0-0.bpo.4-amd64 available in your configured
repositories? If so, what versions is it available with?
It's possible that the 5.10.19-1~bpo10+1 version may be available only
under the updated .4 package name, not under the .3 package name you're
checking.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature