From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QG8ds-0008HL-Ed for garchives@archives.gentoo.org; Sat, 30 Apr 2011 11:47:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B0D81C07E; Sat, 30 Apr 2011 11:47:11 +0000 (UTC) Received: from mail-pw0-f53.google.com (mail-pw0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 4548A1C017 for ; Sat, 30 Apr 2011 11:46:42 +0000 (UTC) Received: by pwj7 with SMTP id 7so3256662pwj.40 for ; Sat, 30 Apr 2011 04:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=3QtH5PhdJrkIswUtkx9n4J+Syg48inb3Bc3cV8eVMHw=; b=S2TjYnjeY/un/fE5W0nQc8pMQ7RI819q7iX3bruQHME5qSAdcmAXWJKkBUuOapz3+r imRb0QzCgywlRdHb7XDHjhRwHR8Vbn0HrhWB4rqcqCVlGMYMVC+M/txV+13ooqoFtZOt w1ZmMdtMmdKDluQMS20g0VK6Gq4xpv+iCtEcY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=mWMfjDnWI1lP0wfNYT2pjv11ckD92eYB6yRblIFCrybS0ddRiKTpjQkeH2f4Fd/uBR zhM1DIARjys1DWYVdo5fNFeeotppbpLwyctZNN4W7VYdZXxgfrNlKzsgDASU+lp9MNPr kZ10mEB52UilXpUssysopN0WorrQr6aiyxh5Y= Received: by 10.68.63.166 with SMTP id h6mr6275331pbs.42.1304164002517; Sat, 30 Apr 2011 04:46:42 -0700 (PDT) Received: from smtp.gmail.com (c-24-20-36-83.hsd1.wa.comcast.net [24.20.36.83]) by mx.google.com with ESMTPS id k1sm2529494pbd.94.2011.04.30.04.46.39 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Apr 2011 04:46:41 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Sat, 30 Apr 2011 04:46:43 -0700 Date: Sat, 30 Apr 2011 04:46:43 -0700 From: Brian Harring To: Duncan <1i5t5.duncan@cox.net> Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: openrc portage news item Message-ID: <20110430114643.GC20648@hrair> References: <20110413181538.GA2894@linux1> <20110421011221.GA1736@eee> <201104221239.11593.polynomial-c@gentoo.org> <20110429184135.GA20648@hrair> <20110430021950.GC6032@linux1> <20110430045945.GB20648@hrair> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="raC6veAxrt5nqIoY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: X-Archives-Hash: 6d442992d5756b36e0817b4fa44f5f47 --raC6veAxrt5nqIoY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > > Checking the boot levels, udev included, same thing- if ROOT=3D/ 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*. >=20 > Um... 32-bit chroots for amd64 comes to mind, tho that's just a single=20 > supported case of the general idea. Here, I've adapted the idea slightly= =20 > by simply installing a complete system to the chroot, just never actually= =20 > /running/ it from there, as a maintained system image that was initially= =20 > transferred to USB, now updated thru rsync, for my netbook. What I'm suggesting is mangling the default configs that get pushed in=20 via postinst to reflect the old configs for the spots where it's=20 necessary. The 32bit/64bit scenario there still is addressable- scan=20 the pre-existing rc-update show. If you're just chroot'ing into the=20 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=20 starting the services in the /first/ place after all, so no further=20 fall out. If you were starting services, udev for example, spotting that and=20 transferring it across isn't hard. It's actually slightly more complex than that to track the settings=20 =66rom setup through postinst, but that's implementation details,=20 secondary issue to my original question. > Portage's ROOT is unchanged in these cases, but depending on how the=20 > detection of the running system is achieved, the script might attempt=20 > changes based on the components of the 64-bit HOST system, not the 32-bit= =20 > chroot system image, or conversely, changes inappropriate for an image=20 > that never actually boots on its host system. That would *NOT* be a good= =20 > thing! Already outlined above how this interpretation is incorrect. It's=20 basically identification of scenarios- your posited (presumably what=20 you run locally since you seem fairly heated about it) scenario looks=20 like it still would fly due to pre-existing configuration being=20 referencable- or you weren't actually configuring it in full, nor=20 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=20 asking why those potentials, from the rough look of it, were ruled=20 out. If they were considered, then it should be reasonably easy to point=20 folks at bugs/discussions clarifying why it wasn't considered viable. 32bit chroot is one example of where it might be dicey, although=20 frankly I still consider that deployment a bit whacked on it's own. =20 I'm looking for more than just that however > Meanwhile, all this is a rather nice idea in theory, but with literally= =20 > days left before pulling the trigger, now's rather late in the game to=20 > bring the suggestion. It's an arbitrary deadline. To be clear, it's an arbitrary deadline=20 that has a horrid ass set of "do these things or your system is=20 fubared", plus that pkg_pretend frankly is a different form of=20 horrible beyond that. While late in the game, frankly it just came to the attention- I've=20 ran openrc basically since day 1. It crossed the radar only recently due to the desired announcement requesting feedback- which means=20 feedback on the change itself, fundamentally.=20 Regardless, what you're offering up here is deflections/excuses to=20 just do it. Which... frankly, that's fine. If that's peoples=20 decision in full, fine, they own that decision. If the potentials weren't explored, it would be useful *knowing* so=20 looking at reducing the pain can be done- if they *were* explored and=20 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? = =20 Chill the hell down. I didn't kick your puppy, nor did I steal your=20 lunch money in 7th grade. I may have mocked your 'flock of seagulls'=20 haircut (or 'bieber' haircut for the younguns), but they're stupid=20 haircuts- it was deserved ;) Joke aside, I asked a valid question. Rhetorical nonsense isn't a=20 valid response, nor useful. > Meanwhile, Gentoo has always been about expecting Gentoo's users to take= =20 > responsibility as their own sysadmins. Yes, we document, and automate=20 > 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=20 exactly why I'm asking this. Yes, users must function as the=20 sysadmin/SA of their system. A proper SA avoids upgrade pathways were possible that require=20 manual intervention. This requires manual intervention. Said proper SA's also have a rather large hatred of anything that can=20 leave a system nonbootable (rant: including crappy SA's who don't=20 verify the !@#*ing thing comes back up in a proper hot/warm state). =20 This qualifies for that. Again, not saying this approach can't be taken if needed- I'm asking=20 what alternatives were ruled out in getting to this point. ~brian --raC6veAxrt5nqIoY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAk279qMACgkQsiLx3HvNzgdSZACfXAl5j0UHNMGjkr+FoJPx9V+2 9PsAoLYoyPik+eOVsod2KCcqzvgPkIVB =ET+4 -----END PGP SIGNATURE----- --raC6veAxrt5nqIoY--