| 1 |
On Sat, Apr 30, 2011 at 07:13:59AM +0000, Duncan wrote: |
| 2 |
> Brian Harring posted on Fri, 29 Apr 2011 21:59:45 -0700 as excerpted: |
| 3 |
> |
| 4 |
> > Checking the boot levels, udev included, same thing- if ROOT=/ and |
| 5 |
> > baselayout is there already you likely *could* look at the running |
| 6 |
> > system to see what's needed/in use, and kick rc-update as needed for |
| 7 |
> > spots where it *isn't*. |
| 8 |
> |
| 9 |
> Um... 32-bit chroots for amd64 comes to mind, tho that's just a single |
| 10 |
> supported case of the general idea. Here, I've adapted the idea slightly |
| 11 |
> by simply installing a complete system to the chroot, just never actually |
| 12 |
> /running/ it from there, as a maintained system image that was initially |
| 13 |
> transferred to USB, now updated thru rsync, for my netbook. |
| 14 |
|
| 15 |
What I'm suggesting is mangling the default configs that get pushed in |
| 16 |
via postinst to reflect the old configs for the spots where it's |
| 17 |
necessary. The 32bit/64bit scenario there still is addressable- scan |
| 18 |
the pre-existing rc-update show. If you're just chroot'ing into the |
| 19 |
sucker without kicking any services within it, you're unaffected |
| 20 |
either way if it rc-update's a couple of services- you weren't |
| 21 |
starting the services in the /first/ place after all, so no further |
| 22 |
fall out. |
| 23 |
|
| 24 |
If you were starting services, udev for example, spotting that and |
| 25 |
transferring it across isn't hard. |
| 26 |
|
| 27 |
It's actually slightly more complex than that to track the settings |
| 28 |
from setup through postinst, but that's implementation details, |
| 29 |
secondary issue to my original question. |
| 30 |
|
| 31 |
|
| 32 |
> Portage's ROOT is unchanged in these cases, but depending on how the |
| 33 |
> detection of the running system is achieved, the script might attempt |
| 34 |
> changes based on the components of the 64-bit HOST system, not the 32-bit |
| 35 |
> chroot system image, or conversely, changes inappropriate for an image |
| 36 |
> that never actually boots on its host system. That would *NOT* be a good |
| 37 |
> thing! |
| 38 |
|
| 39 |
Already outlined above how this interpretation is incorrect. It's |
| 40 |
basically identification of scenarios- your posited (presumably what |
| 41 |
you run locally since you seem fairly heated about it) scenario looks |
| 42 |
like it still would fly due to pre-existing configuration being |
| 43 |
referencable- or you weren't actually configuring it in full, nor |
| 44 |
running the services from w/in it, so it's a non issue anyways. |
| 45 |
|
| 46 |
Either way, I did not say it was necessarily simple; I'm fundamentally |
| 47 |
asking why those potentials, from the rough look of it, were ruled |
| 48 |
out. |
| 49 |
|
| 50 |
If they were considered, then it should be reasonably easy to point |
| 51 |
folks at bugs/discussions clarifying why it wasn't considered viable. |
| 52 |
|
| 53 |
32bit chroot is one example of where it might be dicey, although |
| 54 |
frankly I still consider that deployment a bit whacked on it's own. |
| 55 |
I'm looking for more than just that however |
| 56 |
|
| 57 |
|
| 58 |
> Meanwhile, all this is a rather nice idea in theory, but with literally |
| 59 |
> days left before pulling the trigger, now's rather late in the game to |
| 60 |
> bring the suggestion. |
| 61 |
|
| 62 |
It's an arbitrary deadline. To be clear, it's an arbitrary deadline |
| 63 |
that has a horrid ass set of "do these things or your system is |
| 64 |
fubared", plus that pkg_pretend frankly is a different form of |
| 65 |
horrible beyond that. |
| 66 |
|
| 67 |
While late in the game, frankly it just came to the attention- I've |
| 68 |
ran openrc basically since day 1. It crossed the radar only recently |
| 69 |
due to the desired announcement requesting feedback- which means |
| 70 |
feedback on the change itself, fundamentally. |
| 71 |
|
| 72 |
Regardless, what you're offering up here is deflections/excuses to |
| 73 |
just do it. Which... frankly, that's fine. If that's peoples |
| 74 |
decision in full, fine, they own that decision. |
| 75 |
|
| 76 |
If the potentials weren't explored, it would be useful *knowing* so |
| 77 |
looking at reducing the pain can be done- if they *were* explored and |
| 78 |
discarded, then it saves folks the time of digging into it further. |
| 79 |
|
| 80 |
Simple enough. |
| 81 |
|
| 82 |
|
| 83 |
> Are you actually trying to delay the upgrade to OpenRC /forever/? Why? |
| 84 |
|
| 85 |
Chill the hell down. I didn't kick your puppy, nor did I steal your |
| 86 |
lunch money in 7th grade. I may have mocked your 'flock of seagulls' |
| 87 |
haircut (or 'bieber' haircut for the younguns), but they're stupid |
| 88 |
haircuts- it was deserved ;) |
| 89 |
|
| 90 |
Joke aside, I asked a valid question. Rhetorical nonsense isn't a |
| 91 |
valid response, nor useful. |
| 92 |
|
| 93 |
|
| 94 |
> Meanwhile, Gentoo has always been about expecting Gentoo's users to take |
| 95 |
> responsibility as their own sysadmins. Yes, we document, and automate |
| 96 |
> where reasonably possible, but there's a reason for etc-update, dispatch- |
| 97 |
> conf, etc. |
| 98 |
|
| 99 |
While that's a fun quotation to use, you basically just aligned with |
| 100 |
exactly why I'm asking this. Yes, users must function as the |
| 101 |
sysadmin/SA of their system. |
| 102 |
|
| 103 |
A proper SA avoids upgrade pathways were possible that require |
| 104 |
manual intervention. This requires manual intervention. |
| 105 |
|
| 106 |
Said proper SA's also have a rather large hatred of anything that can |
| 107 |
leave a system nonbootable (rant: including crappy SA's who don't |
| 108 |
verify the !@#*ing thing comes back up in a proper hot/warm state). |
| 109 |
This qualifies for that. |
| 110 |
|
| 111 |
Again, not saying this approach can't be taken if needed- I'm asking |
| 112 |
what alternatives were ruled out in getting to this point. |
| 113 |
|
| 114 |
~brian |
Archives