On Sun, 03 Feb 2013 19:24:50 +0200, Alan McKinnon wrote: > So I say to you > > "Neil, what is your solution for all the myriad configurations possible > that DO NOT resemble your own? We know what your preferred solution is, > as you stated it clearly, but I am interested in all those other users > not covered by that. Please provide a well thought out solution that > works for them as well as yours would work for you." > > I'll bet good money you come to the same conclusion I did (based on the > conclusions on gentoo-dev)::
I haven't had a chance to read the -dev threads but > - trying to infer something from the current running kernel, or > /usr/src/linux/.config or some magic name in /boot/ is pointless and > leads to so many false positives it isn't worth the effort in the > general case. That's what I was thinking of based on 1) Breaking a system to be unbootable is a bad idea 2) The current running kernel is bootable 3) As long as you have that, anything else can be dealt with post-install Cases like compiling for another system aren't relevant, because the message will be seen before the update is applied to the other system. The post-install message can be read on the build host and acted upon before the target system is broken. Rendering a new kernel unbootable is still not a massive problem as long as the current kernel still works. The checks should be run before the emerge process starts, like the pre-emerge checks for the likes of libreoffice and kdelibs. That avoids/ the problem of the /usr/src/symlink being changed in the middle of a world update. > - a console message and an elog generated in one of the *pre hooks is > about as good as it gets ... Which is still a damn sight better than the current "oops, sorry" method. -- Neil Bothwick Normal people believe that if it ain't broke, don't fix it. Engineers believe that if it ain't broke, it doesn't have enough features yet."
signature.asc
Description: PGP signature
