Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration.

[Sergei Trofimovich]

On Tue, 2 Jul 2013 10:21:53 +0200
Fabio Erculiani <lxnay@g.o> wrote:

> On Tue, Jul 2, 2013 at 9:36 AM, Sergei Trofimovich <slyfox@g.o> wrote:
> > [ sorry, a lot to quote ]
> >
> > What upstream do you plan to report bugs when user possibly mixes
> > all of it in one mess? Each of those is known to be unstable. The mix
> > is just a disaster.
> >
> > Is gentoo's kernel team able to resolve user's OOpsen?
> >
> >> ### ... and configuration. ###
> >>
> >> This problem is not only visible for patches, but also in the config.
> >
> > Insane :]
> >
> >> Meet CONFIG_DEVTMPFS; forget to enable it, greet a failing boot. We're
> >> telling users to enable it in some places, in the handbook it's a single
> >> line you must read, on the Wiki it's kind of missing unless you are
> >> luckily on the right page, on the Quick Install book it is missing too.
> >
> > Forbid users install udev to ROOT=/ if running kernel does not support devtmpfs
> > (easy to check by /proc/filesystems)
>
> No. As explained multiple times, this check is not reliable and
> doesn't work (chroot, binpkgs, containers without kernel, and so
> on...).
> Making sure that the user doesn't build an unbootable kernel is the way to go.

udev's case:
It's _not_ the kernel which upgrade breaks user's system. Why do you try to "fix" it?
If you want to save user's box - make check at pre-install time. Otherwise it will break.

containers, etc. case:
If you build gentoo(and, what really matters _install_) in container
- you can run gentoo in container. Yes, with it's stock broken kernel.

Who cares what you have built if the host is xen-3.0.6 with CONFIG_DEVTMPFS=n?
If you really want to proceed unsafe action you need to do it explicitely.

kernel's case:
CONFIG_DEVTMPFS needs 'default yes', right? One-liner to gentoo-sources.
Why 'hide' it? It's very counterintuitive.

What will you do with all-those-required-to-boot-properly
  - root filesystem
  - disk controller
  - USB keyboard drivers
 ?
Include them all unless CONFIG_DONT_REMOVER_OR_WONT_BOOT
option?

I'm afraid I don't see how it's a solution. 
Suppose, tomorrow's udev will require CONFIG_foo, and glibc will require
CONFIG_bar. How will you save user with your mechanism?

-- 

  Sergei