Re: Upcoming changes to Debian Linux kernel packages
>>>>> "Bastian" == Bastian Blank <waldi@debian.org> writes:
Bastian> The same as now: nowhere, because those packages have been
Bastian> removed from the archive already.
Bastian> And sadly you did not answer the question why a second
Bastian> degree error must not be worse then a worked around first
Bastian> degree error?
I'll admit that I find that phrasing difficult enough that I had to read
it a couple of times and I'm still not sure I've got it.
Let me see if I understand what you are saying.
1) kernel headers will be removed from the archive. So people complain
if they have an old kernel and wish to get kernel headers for it, but
those headers have been removed.
2) If the kernel header version changes but the kernel header package
name does not change (version changed but not uname -r in the new
scheme?), you can have what you think is the right kernel headers but
they do not work with the binaries you have installed.
3) you can run into trouble between testing and backports.
I think that's what you mean by the first-level error.
If not, I'm still confused.
In the second level error case you are talking about is:
1) there is a regression in the kernel
2) someone needs kernel headers for an old kernel they want to downgrade
to.
I don't actually see how this is a second level error.
It appears to be a different first-level error (a regression), and the
downgrade appears to follow naturally from that.
You point out that someone may not be able to get kernel headers for the
downgraded kernel.
a) They might. In the window between a new kernel being introduced into
unstable and the same kernel being introduced into testing there is an
old kernel available with kernel headers.
Similarly if someone needs to downgrade as far as stable, there is a
kernel with headers available in stable.
B) They might already have headers installed. Imagine someone who
installs headers at the same time they install the kernel.
Unless they managed to upgrade the same version of their kernel without
also upgrading their headers, they will still have headers.
They can still build modules against that kernel, either because they
installed a new dkms package, or because one of their dkms packages
upgraded.
I think what you are saying is that
1) the current system is fragile: sometimes you want a kernel headers
that is not available and sometimes you have version skew between the
kernel headers and kernel even though you have both installed.
2) In your system, fewer things are possible, but the combination that
is possible is more likely to work.
And I think people's response is that
they care enough about some of the things you are breaking that they are
willing to accept the fragility.
Bastian> -- Each kiss is as the first. -- Miramanee, Kirk's wife,
Bastian> "The Paradise Syndrome", stardate 4842.6
Reply to: