On Sat, Apr 30, 2011 at 07:13:59AM +0000, Duncan wrote:
> 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.

What I'm suggesting is mangling the default configs that get pushed in 
via postinst to reflect the old configs for the spots where it's 
necessary.  The 32bit/64bit scenario there still is addressable- scan 
the pre-existing rc-update show.  If you're just chroot'ing into the 
sucker without kicking any services within it, you're unaffected 
either way if it rc-update's a couple of services- you weren't 
starting the services in the /first/ place after all, so no further 
fall out.

If you were starting services, udev for example, spotting that and 
transferring it across isn't hard.

It's actually slightly more complex than that to track the settings 
from setup through postinst, but that's implementation details, 
secondary issue to my original question.


> 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!

Already outlined above how this interpretation is incorrect.  It's 
basically identification of scenarios- your posited (presumably what 
you run locally since you seem fairly heated about it) scenario looks 
like it still would fly due to pre-existing configuration being 
referencable- or you weren't actually configuring it in full, nor 
running the services from w/in it, so it's a non issue anyways.

Either way, I did not say it was necessarily simple; I'm fundamentally 
asking why those potentials, from the rough look of it, were ruled 
out.

If they were considered, then it should be reasonably easy to point 
folks at bugs/discussions clarifying why it wasn't considered viable.

32bit chroot is one example of where it might be dicey, although 
frankly I still consider that deployment a bit whacked on it's own.  
I'm looking for more than just that however


> 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.

It's an arbitrary deadline.  To be clear, it's an arbitrary deadline 
that has a horrid ass set of "do these things or your system is 
fubared", plus that pkg_pretend frankly is a different form of 
horrible beyond that.

While late in the game, frankly it just came to the attention- I've 
ran openrc basically since day 1.  It crossed the radar only recently
due to the desired announcement requesting feedback- which means 
feedback on the change itself, fundamentally. 

Regardless, what you're offering up here is deflections/excuses to 
just do it.  Which... frankly, that's fine.  If that's peoples 
decision in full, fine, they own that decision.

If the potentials weren't explored, it would be useful *knowing* so 
looking at reducing the pain can be done- if they *were* explored and 
discarded, then it saves folks the time of digging into it further.

Simple enough.


> Are you actually trying to delay the upgrade to OpenRC /forever/?  Why?  

Chill the hell down.  I didn't kick your puppy, nor did I steal your 
lunch money in 7th grade.  I may have mocked your 'flock of seagulls' 
haircut (or 'bieber' haircut for the younguns), but they're stupid 
haircuts- it was deserved ;)

Joke aside, I asked a valid question.  Rhetorical nonsense isn't a 
valid response, nor useful.


> 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.

While that's a fun quotation to use, you basically just aligned with 
exactly why I'm asking this.  Yes, users must function as the 
sysadmin/SA of their system.

A proper SA avoids upgrade pathways were possible that require 
manual intervention.  This requires manual intervention.

Said proper SA's also have a rather large hatred of anything that can 
leave a system nonbootable (rant: including crappy SA's who don't 
verify the !@#*ing thing comes back up in a proper hot/warm state).  
This qualifies for that.

Again, not saying this approach can't be taken if needed- I'm asking 
what alternatives were ruled out in getting to this point.

~brian