On Sat, 2 Feb 2013 16:21:10 +0100 Alex Schuster <wo...@wonkology.org> wrote:
> Michael Mol writes: > > > So, I botched the upgrade to udev-191. I thought I'd followed the > > steps, but I apparently only covered them for one machine, not both. > > [...] > > > Udev also complained about DEVTMPFS not being enabled in the > > kernel.[2] I couldn't get into X, but I could log in via getty and > > a plain old vt, so I enabled it, rebuilt the kernel, installed it > > and rebooted...and now that's presumably covered. > > Ran into the same problem, with my sister's PC. Which I had updated > from remote, so I did not see the elogs. I do not think it is correct > behaviour to continue building udev although the system wouldn't boot > with that kernel option missing. I would expect the udev ebuild to > check the running kernel for that option, and refuse to build until > it has it set. Or until building is forced by some USE flag or an > environment variable. > > Had these things not been handled better in the past? There's a furious debate going on in -dev about this very thing, and the bottom line is that your statements above are way too simplistic. - there is no guarantee that /proc/config.gz represents the kernel the binary will actually run on (this emerge might well be the last process you ever run on that kernel) - there is no guarantee that /usr/src/linux corresponds to anything at all (it's a symlink and can point to anything, even invalid stuff) - there is no guarantee that the build host will run the code (think build farms, crossdev etc, so every available config cannot possibly be valid) - and a couple more Basically, the only thing left for the ebuild devs is to notify the user with the important information. The question is not whether to halt the build or not (that cannot and will not be done) but how to do the communication: - news item - elog - README - some arb notice on a web site somewhere ..... This is gentoo, the distro that does not hold your hand and gives you every opportunity to keep both pieces. This is a good example of such. -- Alan McKinnon alan.mckin...@gmail.com
