Re: [gentoo-kernel] Which Kernel?

[Marc Schiffbauer <mschiff@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5859 bytes --]

Am Mittwoch, 27. Februar 2013, 17:24:39 schrieb Tom Wijsman:
> On Wed, 27 Feb 2013 16:39:22 +0100 Marc Schiffbauer <mschiff@gentoo.org> 
wrote:
> > Why would you want to continue to use an outdated/insecure kernel
> > *from the same series* like 3.7*?
> 
> No time yet to recompile a new kernel, a temporarily broken newer kernel
> (eg. nvidia-drivers doesn't work with it yet), and so on... Just one
> version off doesn't make that much of a difference in date and security.

I agree with that. But in case of nvidia-drivers: I use them myself and never 
saw a case where a minor version upgrade (e.g. 3.7.x -> 3.7.y) was a problem 
here. Upgrading from 3.x to 3.y sure is often a problem for some time.

> 
> > > The majority of users doesn't upgrade on every single release, it is
> > > better to support them in their upgrade schedule instead of forcing
> > > them to upgrade or use more complex approaches to do what they want.
> > 
> > Where would be the force? Uninstall of old sources would happen while
> > they are upgrading.
> 
> It doesn't copy the sources, rebuild and install the kernel though.

Ok. It heavily depends on how one upgrades and gets things done. I for example 
would love to see older releases wihtin the same series disappear on its own 
so I would not have to unmerge them manually.

Tools like eclean-kernel are a great help here of course...

> 
> > I guess you are referring to a use case where user just upgrade
> > packages but would not like to restart the system. This is indeed a
> > use case for exact version slots.
> 
> More is needed than to just restart their system, see my previous
> sentence.

Maybe genkernel could be extended so that it will do minor kernel upgrades 
semi-automatically.

The ebuild might emmit an ewarn like "Please run 'genkernel update'" to build 
updated kernel.

It then would do things like:

* get current kernel from "eselect kernel"
* copy .config to new kernel (newest minor version)
* set new kernel active using "eselect kernel"
* run "make oldconfig"
* run "genkernel all" if modules are enabled or "genkernel bzImage initramfs" 
if not
* run "module-rebuild rebuild"

Only a suggestion. I am aware that not everyone is using genkernel though...


> 
> > Maybe both things yould coexist? Why not have both kinds of SLOTs
> > then?
> 
> Hmm, subslots definitely sound interesting to use; only needs to
> figure out if that fits the case and whether users will understand them.

Sounds interesting.

So you mean something like SLOT="3.7/5" for linux 3.7.5 ?

nvidia-drivers for example could then depend on "gentoo-sources-3.7*:=" if 
that is supported by subslot dependencies.

But that may cause a rebuild of nvidia-drivers before "eselect kernel" has 
been called to point to the new kernel. Maybe that step could be automated 
then if configured somewhere, maybe through a USE flag?


> > > For small packages, it doesn't really matter how you do it; but
> > > setting up the kernel (copy config, make oldconfig) and compiling it
> > > make explicit (un)masking much more annoying than just keeping
> > > multiple versions within a branch around.
> > 
> > Sorry I do not get it. What is your point here? Getting minor kernel
> > updates automatically without having to fiddle with masks/unmaks each
> > time is the goal here IMO.
> 
> I'm not sure which part you didn't get, but be aware that the
> suggested SLOT approach does not keep multiple versions within a branch
> around; which forces the user to upgrade and therefore requires the
> user to do all that I said.

I was not sure if you were suggesting to use more masking/unmasking and 
whether you find that more complex or easier do manage. Nevermind...

Yes it would remove older releases. I got that part.
But when would that be a real problem?
AFAICS only if you install/update packages *after* the kernelsource update and 
*before* kernel rebuild.
Deferring a source update (and removing previous source) to the end of an 
emerge run might help a bit here.

But anyhow we are talking about subslots already which migth be a way better 
solution so we might not deepen that part any further... ;)

> Kernels release way too often for that, and it is not guaranteed that
> newer versions work so users will have to try them first; 

Is that really true for minor updates like 3.7.x -> 3.7.y ?

> if one breaks
> for them, the new SLOT approach would have removed their old sources
> and therefore they would have to start all over with them if they have
> the need to rebuild their kernel or compile something against them.

Ack. But thats the case mainly for feature updates (3.7 -> 3.8)

> There is more than a single goal when talking about changing the SLOT
> syntax, especially for a bigger package like the kernel; users use it
> differently, yielding different reasons for different approaches to
> specify which version are selected and which versions are masked.
> 
> Changing the SLOT syntax makes you need to consider what else changes,
> because it's not really worth pulling off something for a few users
> when it breaks the work flow for the majority of users. 

full ack!

> And note, we're
> pitting of only two or three use cases here, there are possibly more of
> them; I would love to see some regulars join the discussion.
> 
> > So how about just add a new SLOTs for every stable long term kernel
> > release series like "3.4" and leaving current SLOTs as they are?
> 
> Hmm, since stable kernel releases break less often, this might be
> reasonable. This introduces some inconsistency though, although that
> could be abused to make it clear to users that they are LTS series.

Do you remeber any major breakage in a point release?

> 
> I'll try to hear, I need to bug them about 3.4.3x stabilization too.

+1


Cheers
-Marc
-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 190 bytes --]