Hello,
On Sat, Feb 03, 2018 at 09:43:33PM +0000, Michael Fothergill wrote:
> I am trying to suggest one would want to move faster than the approximate
> cycle time of new stable releases here.
You have been repeatedly told that the updates will appear as
security updates in Debian stable when the kernel team judges they
have had an appropriate amount of testing. Security updates do not
wait for the next stable release, nor even the next stable point
release.
You are writing vastly more text in this thread than any other
single correspondent but you don't appear to be particularly
familiar with your subject matter. I suggest that for a newcomer
trying to follow your long and winding tale thinking it is somehow
representative of Debian, *that* would seem like an odyssey, and
there's just no need. The answers were all given in the first few
posts and the rest of it is a combination of you misunderstanding
what Debian is, and you wishing Debian was something that it's not.
> I am concerned about new users and what they would have to to
> install the current kernels (ie use a separate live sid
> distribution (correctly and helpfully referred to by Andy) to
> compile the new kernel and then transfer it to the stable
> install).
Well I didn't say you needed a live distribution, I suggested a
chroot would be the normal way. Unless you consider a chroot to be a
live distribution, which I personally would not, but it is
debatable.
To me a live distribution is something you boot into, whereas a
chroot is a lightweight thing that you just create, launch processes
in and then throw away. No rebooting, etc. Telling people that they
need "a live sid distribution" implies a lot more work than is
actually required.
> That does not seem to me to be ideal for a new user. Hence my
> comment about it not being fit for purpose at present.
The Spectre bugs are quite unusual in that they need a kernel update
*and* a new compiler to build it with (and microcode updates too).
That is a really exceptional set of requirements and it would be
inappropriate to design your whole distribution around that being a
normal state of affairs.
The mere fact that the Debian kernel team is waiting a little while
before pushing new packages into stable does not for me render the
entire distribution "not fit for purpose" - nor even the kernel
team's processes.
*Someone*'s got to do that work and I'd rather
Debian's kernel team did it than have the latest upstream stuff
thrown at the general user base.
Other distributions which track upstream more aggressively are
designed for that. It's part of their contract with their users.
Proposals to make some sort of rolling release version of Debian
that more closely follows upstream have been made many times but
have never come to much. For example:
<https://lists.debian.org/debian-devel/2015/03/msg00045. >html
> It has been suggested to me others on the site that eventually the
> GCC 7.3 compiler might be introduced into Debian Buster whereupon
> it could be used to compile the latest kernels.
I don't know what the plans are for gcc but that would make things a
little easier, yes. However the route to a fix for the majority of
Debian users will be to receive new binary kernel packages from a
security update. Which is even easier.
> The odyssey is debian itself as I see it.
…because you went on a learning experience and instead of doing what
multiple people suggested, went down some very long dead ends of
your own.
If you want to make genuine constructive suggestions for how things
could be improved, I think you should start by identifying what
exactly the deficiencies are.
A lot of this thread seems to have been along the lines of "it's too
hard to build Debian kernel packages that are fixed against Spectre
and Meltdown", but the point is marred by a) you taking a lot of
wrong turns, and b) the Spectre bugs being quite exceptional in how
they can be mitigated.
Having to build a chroot and then rebuild a kernel package with the
gcc inside that chroot sounds tricky but it's actually fairly easy
once you've done it once. Given how rare it is to need to do that,
I'm not convinced it is that onerous or that it is any kind of
condemnation of Debian.
If that is *not* what you consider the deficiency to be, can you
succinctly explain what it is?
Cheers,
Andy