1 |
On Fri, Apr 29, 2011 at 09:19:50PM -0500, William Hubbs wrote: |
2 |
> On Fri, Apr 29, 2011 at 11:41:35AM -0700, Brian Harring wrote: |
3 |
> > Exact results please; the pkg_pretend crap proposed elsewhere (which |
4 |
> > is yet another way to crap up stage builds) frankly sucks. |
5 |
> > |
6 |
> > Mind you I'm just looking in, but this whole upgrade process really |
7 |
> > reads fairly suboptimal to me. It's definitely possible that this is |
8 |
> > the best that can be done, but I'd like to see exactly which issues we |
9 |
> > can't resolve in some fashion via pkg_postinst tricks w/in openrc. |
10 |
> > |
11 |
> > I'd much rather have an ebuild that violates a few rules than forced |
12 |
> > "you must accept this beyond normal mechanisms" and potential "can't |
13 |
> > boot" upgrade processes. |
14 |
> > |
15 |
> > So... details please, and why we can't script our way past chunks of |
16 |
> > this. :) |
17 |
> |
18 |
> The biggest part of the migration is running dispatch-conf, etc-update |
19 |
> or another configuration file updater and accepting all of the openrc |
20 |
> changes. |
21 |
|
22 |
Yeah, with respect this is the hand wavey part I wanted details for. |
23 |
I wanted to know *which* files were incompatible in conf differences, |
24 |
things like that. From the sounds of it, the main concern is a set of |
25 |
files moving (including their format), and CONFIG_PROTECT firing- it |
26 |
takes some planning, but it's possible to work around this (suppress |
27 |
it if needs be) or do pkg_postinst tricks outside the PM's normal |
28 |
protections for it. |
29 |
|
30 |
|
31 |
> Most of the stuff in the migration guide is just directing |
32 |
> you to verify changes that the openrc ebuild has made and telling you |
33 |
> which configuration files may need to be altered to match your system. |
34 |
> I'm not sure how to script passed any of that. |
35 |
|
36 |
Migration of settings from /etc/conf.d/rc to /etc/rc strikes me as |
37 |
pretty damn scriptable, within limits- I've not used non-openrc for a |
38 |
*long* time, but the settings are basically booleans or simple string. |
39 |
Just requires a mapping of conf.d/rc:value -> rc:value . |
40 |
|
41 |
Kernel modules, no different. |
42 |
|
43 |
Checking the boot levels, udev included, same thing- if ROOT=/ and |
44 |
baselayout is there already you likely *could* look at the running |
45 |
system to see what's needed/in use, and kick rc-update as needed for |
46 |
spots where it *isn't*. |
47 |
|
48 |
So... yeah, scriptable, at least from where I'm sitting. To do it, |
49 |
need to snapshot that info, and kick it via pkg_postinst. |
50 |
|
51 |
I realize it's more work, but I'm frankly a bit concerned this isn't |
52 |
beng looked at ("you must run etc-update" isn't the level of detail I |
53 |
expected neither), nor trying very, very hard to remove the potential |
54 |
of non-bootable system here- trying to rely on pkg_pretend nastyness |
55 |
just sidesteps it and introduces other issues. |
56 |
|
57 |
Again, I'm aware it may not be possible, but sharing the details of |
58 |
why this it *isn't* an option would be rather useful. |
59 |
|
60 |
Cheers- |
61 |
~brian |