| 1 |
On Fri, 2007-10-26 at 18:57 +0000, Duncan wrote: |
| 2 |
> Roy Marples <uberlord@g.o> posted |
| 3 |
> 1193418183.3487.3.camel@××××××××××××××.name, excerpted below, on Fri, 26 |
| 4 |
> Oct 2007 18:03:03 +0100: |
| 5 |
> |
| 6 |
> > Fair enough, but one of the goals of baselayout-2 is to support |
| 7 |
> > baselayout-1 configs where possible if the shell is still bash. |
| 8 |
> > |
| 9 |
> > I'm striving to support similar configs for non bash shells so that |
| 10 |
> > there's not much of a learning curve. |
| 11 |
> > |
| 12 |
> > Yes we could have a totally new non compatible setup, but that would |
| 13 |
> > really suck hard for upgraders yes? |
| 14 |
> |
| 15 |
> Unless I misunderstood something, and as certainly the example you gave |
| 16 |
> showed, backward compatibility would be pretty simple: just throw the |
| 17 |
> entire array in the eth0_extra_options= line or whatever. |
| 18 |
|
| 19 |
Not really, as we have a function that maps the existing bash array into a posix shell equivalent. |
| 20 |
|
| 21 |
> So after implementing individual vars, there should be two viable options |
| 22 |
> for upgrading users. (1) Simply stick the array in the _extra_options |
| 23 |
> vars with only minimal (if any) format changes, or break it up into the |
| 24 |
> individual values. Presumably the individual values would be recommended |
| 25 |
> as the supported choice going forward, but the shove-it-all-in-the- |
| 26 |
> options option would be there as well, for those who didn't want to |
| 27 |
> bother with more at that moment. |
| 28 |
|
| 29 |
One issue with that is there is no automatic way of doing that. We just |
| 30 |
pass the array elements onto the various programs |
| 31 |
|
| 32 |
config_eth0=( "1.2.3.4/24" "some voodoo" ) |
| 33 |
becomes |
| 34 |
ifconfig eth0 1.2.3.4/24 |
| 35 |
ifconfig eth0 some voodoo |
| 36 |
|
| 37 |
We also do the same for iproute2 which has a very comples language |
| 38 |
structure. We also do this for most of the helper programs that we use - |
| 39 |
vlan, bridging, wireless just to name a few. |
| 40 |
|
| 41 |
Do we want variables for every single possibility? |
| 42 |
|
| 43 |
The beauty with the array structure is that it allows the user to define |
| 44 |
a sequence of commands to send to a helper. The issue with the array |
| 45 |
structure is that it is bash and we strive to support non bash shells |
| 46 |
hence the discussion. |
| 47 |
|
| 48 |
Oh yes, and transparently supporting the bash config where possible. |
| 49 |
|
| 50 |
> Of course, that's still assuming the folks actually doing the baselayout2 |
| 51 |
> work (you, and I'm not sure how many others working with you) ultimately |
| 52 |
> decide that it's worth the trouble to change. I do honestly believe from |
| 53 |
> a user perspective it'll be easier to maintain and thus more trouble-free |
| 54 |
> if an individual values setup is ultimately chosen, but it's certainly |
| 55 |
> more work to setup from an implementation perspectiv, and very pointedly, |
| 56 |
> I'm not the one doing that work, so it's very easy for me to sit here and |
| 57 |
> get all fancy about how it "should" be done. =8^) IOW, it's very much |
| 58 |
> your call. You just asked for opinions and I'm happily giving mine. =8^) |
| 59 |
|
| 60 |
Well, someone else will have to do that as I sure won't. |
| 61 |
|
| 62 |
Thanks |
| 63 |
|
| 64 |
Roy |
| 65 |
|
| 66 |
-- |
| 67 |
gentoo-dev@g.o mailing list |
Archives