On Tue, 2 Jul 2013 10:21:53 +0200 Fabio Erculiani <[email protected]> wrote:
> On Tue, Jul 2, 2013 at 9:36 AM, Sergei Trofimovich <[email protected]> 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
signature.asc
Description: PGP signature
