Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: Duncan <1i5t5.duncan@×××.net>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: openrc portage news item
Date: Sat, 30 Apr 2011 11:47:20
Message-Id: 20110430114643.GC20648@hrair
In Reply to: [gentoo-dev] Re: openrc portage news item by Duncan <>
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.
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.
24 If you were starting services, udev for example, spotting that and
25 transferring it across isn't hard.
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.
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!
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.
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.
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.
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
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.
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.
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.
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.
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.
80 Simple enough.
83 > Are you actually trying to delay the upgrade to OpenRC /forever/? Why?
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 ;)
90 Joke aside, I asked a valid question. Rhetorical nonsense isn't a
91 valid response, nor useful.
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.
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.
103 A proper SA avoids upgrade pathways were possible that require
104 manual intervention. This requires manual intervention.
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.
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.
114 ~brian


Subject Author
Re: [gentoo-dev] Re: openrc portage news item Rich Freeman <rich0@g.o>