1 |
Roy Marples <uberlord@g.o> posted |
2 |
1193418183.3487.3.camel@××××××××××××××.name, excerpted below, on Fri, 26 |
3 |
Oct 2007 18:03:03 +0100: |
4 |
|
5 |
> Fair enough, but one of the goals of baselayout-2 is to support |
6 |
> baselayout-1 configs where possible if the shell is still bash. |
7 |
> |
8 |
> I'm striving to support similar configs for non bash shells so that |
9 |
> there's not much of a learning curve. |
10 |
> |
11 |
> Yes we could have a totally new non compatible setup, but that would |
12 |
> really suck hard for upgraders yes? |
13 |
|
14 |
Unless I misunderstood something, and as certainly the example you gave |
15 |
showed, backward compatibility would be pretty simple: just throw the |
16 |
entire array in the eth0_extra_options= line or whatever. |
17 |
|
18 |
Besides, the idea is that the vars should be almost self-documenting for |
19 |
at least the "simple" setups, so while there'd certainly be a conversion |
20 |
necessary, for those "simple" setups, it should be as easy to explain |
21 |
that as it will be/is to explain the rules for converting to arrays and |
22 |
have them get it right (said as one who has done the conversion to the |
23 |
present baselayout-2 format and screwed up something dumb in the |
24 |
process). Converting the somewhat "magic" array from one form to |
25 |
another, due to that "magic", is going to be more error prone than |
26 |
converting to vars of the type Gentoo users already use every day, each |
27 |
with a single defined purpose, no fancy format necessary. That's for the |
28 |
"simple" setups. The more complex setups by definition should have folks |
29 |
that understand those setups well enough to do the conversion without |
30 |
major issue, since they pretty much had to in ordered to create them in |
31 |
the first place. |
32 |
|
33 |
So after implementing individual vars, there should be two viable options |
34 |
for upgrading users. (1) Simply stick the array in the _extra_options |
35 |
vars with only minimal (if any) format changes, or break it up into the |
36 |
individual values. Presumably the individual values would be recommended |
37 |
as the supported choice going forward, but the shove-it-all-in-the- |
38 |
options option would be there as well, for those who didn't want to |
39 |
bother with more at that moment. |
40 |
|
41 |
Of course, that's still assuming the folks actually doing the baselayout2 |
42 |
work (you, and I'm not sure how many others working with you) ultimately |
43 |
decide that it's worth the trouble to change. I do honestly believe from |
44 |
a user perspective it'll be easier to maintain and thus more trouble-free |
45 |
if an individual values setup is ultimately chosen, but it's certainly |
46 |
more work to setup from an implementation perspectiv, and very pointedly, |
47 |
I'm not the one doing that work, so it's very easy for me to sit here and |
48 |
get all fancy about how it "should" be done. =8^) IOW, it's very much |
49 |
your call. You just asked for opinions and I'm happily giving mine. =8^) |
50 |
|
51 |
Of course, as I'm already on baselayout2, I'll be bug testing whatever is |
52 |
ultimately decided. =8^) |
53 |
|
54 |
-- |
55 |
Duncan - List replies preferred. No HTML msgs. |
56 |
"Every nonfree program has a lord, a master -- |
57 |
and if you use the program, he is your master." Richard Stallman |
58 |
|
59 |
-- |
60 |
gentoo-dev@g.o mailing list |