| 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 |
Archives