Am Tue, 30 Aug 2016 08:47:22 +0100
schrieb Neil Bothwick <n...@digimed.co.uk>:

> On Tue, 30 Aug 2016 08:34:55 +0200, Kai Krakow wrote:
> 
> > Surprise surprise, 4.7 has this (still not fully fixed) oom-killer
> > bug. When I'm running virtual machines, it still kicks in. I wanted
> > to stay on 4.6.x until 4.8 is released, and only then switch to
> > 4.7. Now I was forced early (I'm using btrfs), and was instantly
> > punished by doing so:  
> 
> No one forced you to do anything. You 4.6 kernel was still in boot,
> your 4.6 sources were still installed. The ebuild was only removed
> fro the portage tree, nothing was uninstalled from your system unless
> you did it. Even the ebuild was still on your computer in /var/db/pkg.

Of course nobody forced me. I just can't follow how the 4.7 ebuild
kind-of replaced the 4.6 (and others) ebuild in face of this pretty
mature oom-killer problem.

Removal of a 4.6 series ebuild also means there would follow no updates
- so my next upgrade would "force" me into deciding going way down
(probably a bad idea) or up into unknown territory (and this showed:
can also be a problem). Or I can stay with 4.6 until depclean removed
it for good (which will, by the way, remove the files from /usr/src).

I think masking had been a much more fair option, especially because
portage has means of displaying me the reasoning behind masking it.

In the end, I simply was really unprepared for this - and this is
usually not how Gentoo works and always worked for me. I'm used to
Gentoo doing better.

Even if the 4.6 series were keyworded - in case of kernel packages they
should not be removed without masking first. I think a lot of people
like to stay - at least temporary - close to kernel mainline because
they want to use the one or other feature.

And then my workflow is always like this: If an ebuild is removed, it's
time to also remove it from my installation and replace it with another
version or an alternative. I usually do this during the masking phase.

-- 
Regards,
Kai

Replies to list-only preferred.

Attachment: pgpobN_vaAsJW.pgp
Description: Digitale Signatur von OpenPGP

Reply via email to