On Sat, Feb 2, 2013 at 2:17 PM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > 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.
I'm no longer subscribed to -dev, so I must have missed that thread.[1] My *preference* in these matters is twofold: 1) Don't depend on the running kernel. I'd like to be able to use portage to cross-compile from one amd64 box to another[2], and the running kernel will be different from the kernel I'm compiling for. 2) Just as we have autounmask-write to force us through a manual confirmation step if we have to change USE flags or unmask something, I'd like autounmask to be able to service an "are you sure you want to override this particular serious warning?" behavior. It'd actually be pretty simple to do with per-package USE flags, and, since autounmask only operates on exact versions of packages, you'd be asked for confirmation on every upgrade. Yes, autounmask makes a mess of /etc/portage/package.use over time, but that's why you should periodically go through and sweep the cobwebs out of there. [1] What with unexpectedly losing my job, I suddenly had even less time than I already had, since I needed to dive full-bore into job hunting. [2] Different CFLAGS, distcc isn't a good option in my circumstance, and I'd risk an "illegal instruction" error a binary in a chroot used an instruction available on the target machine's CPU, but not on the source machine's CPU. -- :wq
