Brian Harring posted on Fri, 29 Apr 2011 21:59:45 -0700 as excerpted: > Checking the boot levels, udev included, same thing- if ROOT=/ and > baselayout is there already you likely *could* look at the running > system to see what's needed/in use, and kick rc-update as needed for > spots where it *isn't*.
Um... 32-bit chroots for amd64 comes to mind, tho that's just a single supported case of the general idea. Here, I've adapted the idea slightly by simply installing a complete system to the chroot, just never actually /running/ it from there, as a maintained system image that was initially transferred to USB, now updated thru rsync, for my netbook. Portage's ROOT is unchanged in these cases, but depending on how the detection of the running system is achieved, the script might attempt changes based on the components of the 64-bit HOST system, not the 32-bit chroot system image, or conversely, changes inappropriate for an image that never actually boots on its host system. That would *NOT* be a good thing! So any such detection would have to be based on far more than the setting for ROOT and existence of baselayout. Meanwhile, all this is a rather nice idea in theory, but with literally days left before pulling the trigger, now's rather late in the game to bring the suggestion. Development and proper testing of such a script would certainly take months, at least. This whole idea, suggested now, seems to me to be a rather advanced case of letting the perfect be the enemy of the far better but nobody claiming perfect. The time for such a suggestion would have been several months ago when the final push toward stabilization and development of the final migration technique was announced. And certainly, trying to shove the required development and testing into anything less something like six more months reasonable minimum, is folly indeed. Meanwhile, existing stable gets further and further behind and harder to maintain, and Gentoo looks more and more "legacy". Are you actually trying to delay the upgrade to OpenRC /forever/? Why? There's other questions I could ask but there ARE things worse than unasked questions. I'm seriously fighting the urge to go there as that bit of list history is something that doesn't need repeated, for sure. Meanwhile, Gentoo has always been about expecting Gentoo's users to take responsibility as their own sysadmins. Yes, we document, and automate where reasonably possible, but there's a reason for etc-update, dispatch- conf, etc. This is as good a case for letting Gentoo users take ultimate responsibility as admins on their own systems as it gets. We've waited long enough. The guides are ready. The systems are ready. The warnings are ready. Now it's time to pull that trigger. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
