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 1QG2I5-0000Vs-Jv for garchives@archives.gentoo.org; Sat, 30 Apr 2011 05:00:25 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 80DE81C011; Sat, 30 Apr 2011 05:00:16 +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 19652E0477 for ; Sat, 30 Apr 2011 04:59:44 +0000 (UTC) Received: by pwj7 with SMTP id 7so3128041pwj.40 for ; Fri, 29 Apr 2011 21:59:44 -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=QUKsKlcueBJM8KeWzalX/Ppw+JHwhRH/lrjN7ECPVuU=; b=CKryWWP2zeLpBinffvgoeTbck6+cvF7Qrc62a3Gh5JIVcIFPHSVnkO/UwMcsj6WcWm dZNcXgi9rIf6NWStIbZQpsYeKmbaI5HdqNglsNf1OIZPYv6g0PZasZE1gLoueK1rcoCB 9b2z1PxSdHZXGr30WXVCLZiXC2/8OlmX+mwAo= 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=q5tNrn58LcFoVgJwA3HB73o0GpZxJrVRJ040q8ELxvaqnO/PbKu3xjcHHuAzs2bYAg 3oKElldNBtyRP5Dsxra8mYDa9UrHGULkubJjheV8mUUEU52RZLR5jZ7gOjolEHvwM9M7 ktFPz9hlDnniZDE1mr6NQxfFd/GJb243xe60U= Received: by 10.68.39.168 with SMTP id q8mr5841088pbk.118.1304139584273; Fri, 29 Apr 2011 21:59:44 -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 v9sm2349376pbu.46.2011.04.29.21.59.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2011 21:59:43 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Fri, 29 Apr 2011 21:59:45 -0700 Date: Fri, 29 Apr 2011 21:59:45 -0700 From: Brian Harring To: William Hubbs Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] openrc portage news item Message-ID: <20110430045945.GB20648@hrair> References: <20110413181538.GA2894@linux1> <20110421011221.GA1736@eee> <201104221239.11593.polynomial-c@gentoo.org> <20110429184135.GA20648@hrair> <20110430021950.GC6032@linux1> 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="TakKZr9L6Hm6aLOc" Content-Disposition: inline In-Reply-To: <20110430021950.GC6032@linux1> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: X-Archives-Hash: c908920c9a7211ff27391164daac04eb --TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 29, 2011 at 09:19:50PM -0500, William Hubbs wrote: > On Fri, Apr 29, 2011 at 11:41:35AM -0700, Brian Harring wrote: > > Exact results please; the pkg_pretend crap proposed elsewhere (which=20 > > is yet another way to crap up stage builds) frankly sucks. > >=20 > > Mind you I'm just looking in, but this whole upgrade process really=20 > > reads fairly suboptimal to me. It's definitely possible that this is= =20 > > the best that can be done, but I'd like to see exactly which issues we= =20 > > can't resolve in some fashion via pkg_postinst tricks w/in openrc. > > > > I'd much rather have an ebuild that violates a few rules than forced=20 > > "you must accept this beyond normal mechanisms" and potential "can't=20 > > boot" upgrade processes. > > > > So... details please, and why we can't script our way past chunks of=20 > > this. :) >=20 > The biggest part of the migration is running dispatch-conf, etc-update > or another configuration file updater and accepting all of the openrc > changes. Yeah, with respect this is the hand wavey part I wanted details for. =20 I wanted to know *which* files were incompatible in conf differences,=20 things like that. From the sounds of it, the main concern is a set of=20 files moving (including their format), and CONFIG_PROTECT firing- it=20 takes some planning, but it's possible to work around this (suppress=20 it if needs be) or do pkg_postinst tricks outside the PM's normal=20 protections for it. > Most of the stuff in the migration guide is just directing > you to verify changes that the openrc ebuild has made and telling you > which configuration files may need to be altered to match your system. > I'm not sure how to script passed any of that. Migration of settings from /etc/conf.d/rc to /etc/rc strikes me as=20 pretty damn scriptable, within limits- I've not used non-openrc for a=20 *long* time, but the settings are basically booleans or simple string. =20 Just requires a mapping of conf.d/rc:value -> rc:value . Kernel modules, no different. Checking the boot levels, udev included, same thing- if ROOT=3D/ and=20 baselayout is there already you likely *could* look at the running=20 system to see what's needed/in use, and kick rc-update as needed for=20 spots where it *isn't*. So... yeah, scriptable, at least from where I'm sitting. To do it,=20 need to snapshot that info, and kick it via pkg_postinst. I realize it's more work, but I'm frankly a bit concerned this isn't=20 beng looked at ("you must run etc-update" isn't the level of detail I=20 expected neither), nor trying very, very hard to remove the potential=20 of non-bootable system here- trying to rely on pkg_pretend nastyness=20 just sidesteps it and introduces other issues. Again, I'm aware it may not be possible, but sharing the details of=20 why this it *isn't* an option would be rather useful. Cheers- ~brian --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAk27l0EACgkQsiLx3HvNzgdiJACfRzXvl6rGToCYqo/qZz/txKLI nCAAni+/Hdf3ORYOAS4U5mnX8OMDwehV =FWeV -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc--