During today's fresh install it showed that the latest stable gentoo-sources has config values that are incompatible with udev >= 181, while stage 3 ships with that version. Can the .config be adjusted to include udev-friendly values by default?
I "answer" here just in order not to leave this interesting suggestion unanswered and only as far as one element of the "potentially others" set is concerned. 1/ It should first be mentioned that a patch "fixing" this bug has been submitted to upstream but was NAKed by kernel devs. 2/ Generally speaking about kernel default CONFIG options, my opinion is that, if any default settings are needed (I do not think they are, who uses the defconfig target anyway ?) they should be implemented according to the frame Linus & other contributors are trying to define there : https://lkml.org/lkml/2012/7/13/369 3/ More specifically speaking about "udev-friendly" CONFIG settings : What do you believe they should be ? (exhaustively) OK! CONFIG_DEVTMPFS, that could be understood as the most obvious one, do you really think that some kernel maintainer can feel authorized to set default an option that was until recently commented with : "If unsure, say N here" ? and knowing that an appreciable amount of CONFIG_DEVTMPS-unset systems do operate well ? Let's go with more easily questionable settings : CONFIG_CGROUPS, do you really think wise to set default "esoteric things that no normal person would want to use" simply because they would suddenly appear here and now (and for how long) used for basic infrastructure and reported compulsory in some obscure upstream-udev readme ? Well, I get under my eyes a few dozens of systems running recent Linux kernels and recent udev... and working perfectly well CONFIG_CGROUPS-unset ! 4/ While your suggestion might appear necessary for whatever binary distro, I do not think that, in the Gentoo world, it would be a good thing for an *sources package to speculate on other components of the system, this including device managers and init systems. As a personal conclusion, while I find this suggestion interesting, I must say that I do not like it. If an appreciable amount of Gentoo users vote for it, then we certainly should think about it accordingly to Linus' suggestion but then, we would certainly need "someone" able to precisely define the set of CONFIG options without which most Gentoo systems won't work, because these are exactly those that should be flagged default. "friendlyness" is not, per se, a sufficient reason. BTW... I... never met that "someone"... !
(In reply to comment #0) > During today's fresh install it showed that the latest stable gentoo-sources > has config values that are incompatible with udev >= 181, while stage 3 > ships with that version. Looking at how new users approach Gentoo, we see this: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7#doc_chap3_pre1 > Next select Maintain a devtmpfs file system to mount at /dev so that critical device files are already available early in the boot process. > [*] Maintain a devtmpfs filesystem to mount at /dev Similarly we have: > # grep DEVTMPFS /usr/share/genkernel/defaults/kernel-config > CONFIG_DEVTMPFS=y So, if they follow the handbook they will end up with the option enabled regardless of which option they choose for the kernel. For the quick install guide (http://www.gentoo.org/doc/en/gentoo-x86-quickinstall.xml), this becomes more problematic; since it doesn't mention such thing. So, it might be worth filing a bug such that they can add a notice for that. (In reply to comment #0) > Can the .config be adjusted to include udev-friendly values by default? I'm not sure what other udev-friendly values we would be talking about, but let's keep this bug restricted to CONFIG_DEVTMPFS to not introduce extra noise. Using the decisions and what we learned from the resolution of this bug, we can easily deal with other options later as needed. Certain questions arise: - Can we defer from what upstream has chosen to do? - Do our kernel sources need to deal with device managers? - Can we force any "Gentoo" defaults upon our users? - Is a default really needed? Aren't the instructions sufficient? Looking back into history whether something similar has already been done in the past, as well as learning from other distributions; might help with answering these questions. Only when there is a positive consensus to those questions, one can ask: - What are the benefits of enabling CONFIG_DEVTMPFS by default? - What are the drawbacks of enabling CONFIG_DEVTMPFS by default? Unless you have some background and experience with this, I don't think this is an easy decision to make. (In reply to comment #1) > 1/ It should first be mentioned that a patch "fixing" this bug has been submitted to upstream but was NAKed by kernel devs. Exactly, for reference: http://thread.gmane.org/gmane.linux.kernel/1331515 (In reply to comment #1) > 2/ ... if any default settings are needed (I do not think they are, who uses the defconfig target anyway ?) they should be implemented according to the frame Linus & other contributors are trying to define ... New users that pick manual actually do, the documentation doesn't refer to kernel seeds or go into any details. But yeah, better options are adding to a kernel seed (might enable DEVTMPFS by default) or trimming down the genkernel config (enables DEVTMPFS by default). The suggestion they make there is interesting, if we do decide to go with introducing "Gentoo" defaults it would give people that customize them an easy way to turn all our defaults off at once. (In reply to comment #1) > ... we would certainly need "someone" able to precisely define the set of CONFIG options without which most Gentoo systems won't work ... > BTW... I... never met that "someone"... ! If we go through with this, I would say "Divide and Conquer". One option at a time would do, we only need to define what "most" and "works" means here...
Turns out, the request got escalated into two separate discussions. I'll provide a more detailed opinion on both. For the actual fix, I'll take this discussion to apply to DEVTMPFS and gentoo-sources (or genpatches, see later), although by extension the same argumentation and consequent conclusions will be valid for several pairs of config settings and ebuilds. (in reply to comment #1) > 1/ It should first be mentioned that a patch "fixing" this bug has been submitted to upstream but was NAKed by kernel devs. I should note here that gentoo-sources is already a patched version of the linux kernel, and if the upstream maintainers refuse a gentoo-specific setting for not fitting the other system layouts elsewhere, it's their choice, not to be an excuse to be forwarded here. After all, it is very much possible to add such a patch in gentoo-sources (which would probably imply genpatches) that changes the default for those ebuilds only without needing upstream intervention. Alternatively, it may be maintainer wisdom to wait out the distroconfig update, since both eventually prevent the issue from ever appearing. As to supplement to the policy discussion, and my real cause of concern, the udev update changed the scene in such a fashion that compiling gentoo-sources without touching any options went from a typically working kernel to one that never works unless changes are effected - be it DEVTMPFS or an udev replacement. While it would not strike new users as they are supposed to read the manual, it does so for people like me who have run the sequence often enough to attempt it blindly and where it consequently appears as an regression. For a comparison of a previous similar event, look at the switch to OpenRC. While it came with a page of warning signs and fixes one potentially needed to perform, it was never again an issue for any new installs. The thing is, for any future kernel upgrades, the same settings need to be fixed over again, and while there is now one obvious culprit, accepting this as acceptable implies that when the system grows increasingly more complicated we can end up with more and more settings that need to be fixed, possibly invoked by various separate packages. Is it an acceptable result that the user gets a full page (or more) with all the settings that need changing to make any recommended kernel they choose even end up in a functional system? And if so, is that still acceptable when a viable solution is provided by upstream (in the form of the RFC'ed distroconfig, or potentially otherwise)? In the end, both turn out to be policy decisions, and I hope you can make a well-founded decision to resolve this.
The amount of users complaining has decreased (as they are properly informed in multiple ways) and no developers seem to want to participate in this discussion, someone still needs to mention this in the Quick Install revise (which probably is going to happen on the Gentoo Wiki). So, unless a lot more users and developers call for this; I'm closing this for now...
*** Bug 467074 has been marked as a duplicate of this bug. ***
