public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* Re: [gentoo-dev] openrc portage news item
  @ 2011-04-30  4:59 99%           ` Brian Harring
  0 siblings, 0 replies; 1+ results
From: Brian Harring @ 2011-04-30  4:59 UTC (permalink / raw
  To: William Hubbs; +Cc: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 2886 bytes --]

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 
> > is yet another way to crap up stage builds) frankly sucks.
> > 
> > Mind you I'm just looking in, but this whole upgrade process really 
> > reads fairly suboptimal to me.  It's definitely possible that this is 
> > the best that can be done, but I'd like to see exactly which issues we 
> > 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 
> > "you must accept this beyond normal mechanisms" and potential "can't 
> > boot" upgrade processes.
> >
> > So... details please, and why we can't script our way past chunks of 
> > this. :)
> 
> 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.  
I wanted to know *which* files were incompatible in conf differences, 
things like that.  From the sounds of it, the main concern is a set of 
files moving (including their format), and CONFIG_PROTECT firing- it 
takes some planning, but it's possible to work around this (suppress 
it if needs be) or do pkg_postinst tricks outside the PM's normal 
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 
pretty damn scriptable, within limits- I've not used non-openrc for a 
*long* time, but the settings are basically booleans or simple string.  
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=/ 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*.

So... yeah, scriptable, at least from where I'm sitting.  To do it, 
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 
beng looked at ("you must run etc-update" isn't the level of detail I 
expected neither), nor trying very, very hard to remove the potential 
of non-bootable system here- trying to rely on pkg_pretend nastyness 
just sidesteps it and introduces other issues.

Again, I'm aware it may not be possible, but sharing the details of 
why this it *isn't* an option would be rather useful.

Cheers-
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[relevance 99%]

Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2011-04-13 18:15     [gentoo-dev] openrc portage news item William Hubbs
2011-04-14 10:32     ` Kfir Lavi
2011-04-21  1:12       ` Donnie Berkholz
2011-04-22 10:39         ` Lars Wendler
2011-04-29 18:41           ` Brian Harring
2011-04-30  2:19             ` William Hubbs
2011-04-30  4:59 99%           ` Brian Harring

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox