From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1IlWbi-0004VM-PR for garchives@archives.gentoo.org; Fri, 26 Oct 2007 21:20:43 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.1/8.14.0) with SMTP id l9QLJpsb021475; Fri, 26 Oct 2007 21:19:51 GMT Received: from mail.marples.name (rsm.demon.co.uk [80.177.111.50]) by robin.gentoo.org (8.14.1/8.14.0) with ESMTP id l9QLHmBQ018926 for ; Fri, 26 Oct 2007 21:17:49 GMT Received: from [10.73.1.30] (uberpc.marples.name [10.73.1.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTP id 93DBB190102 for ; Fri, 26 Oct 2007 22:17:48 +0100 (BST) Subject: Re: [gentoo-dev] Re: Opinions Wanted - Arrays again :) From: Roy Marples To: gentoo-dev@lists.gentoo.org In-Reply-To: References: <1193326831.4245.16.camel@uberlaptop.marples.name> <20071025213113.GJ29642@supernova> <1193348959.2910.9.camel@uberpc.marples.name> <20071025225641.GK29642@supernova> <1193380105.2913.1.camel@uberpc.marples.name> <4721BE92.4070200@thefreemanclan.net> <1193395366.4312.14.camel@uberlaptop.marples.name> <1193418183.3487.3.camel@uberpc.marples.name> Content-Type: text/plain Organization: Gentoo Date: Fri, 26 Oct 2007 22:17:27 +0100 Message-Id: <1193433447.3487.11.camel@uberpc.marples.name> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 73985c15-e6e2-44ed-8338-4734f8a9db99 X-Archives-Hash: c4514fff1b10f881e0b748b618eff8e6 On Fri, 2007-10-26 at 18:57 +0000, Duncan wrote: > Roy Marples posted > 1193418183.3487.3.camel@uberpc.marples.name, excerpted below, on Fri, 26 > Oct 2007 18:03:03 +0100: > > > Fair enough, but one of the goals of baselayout-2 is to support > > baselayout-1 configs where possible if the shell is still bash. > > > > I'm striving to support similar configs for non bash shells so that > > there's not much of a learning curve. > > > > Yes we could have a totally new non compatible setup, but that would > > really suck hard for upgraders yes? > > Unless I misunderstood something, and as certainly the example you gave > showed, backward compatibility would be pretty simple: just throw the > entire array in the eth0_extra_options= line or whatever. Not really, as we have a function that maps the existing bash array into a posix shell equivalent. > So after implementing individual vars, there should be two viable options > for upgrading users. (1) Simply stick the array in the _extra_options > vars with only minimal (if any) format changes, or break it up into the > individual values. Presumably the individual values would be recommended > as the supported choice going forward, but the shove-it-all-in-the- > options option would be there as well, for those who didn't want to > bother with more at that moment. One issue with that is there is no automatic way of doing that. We just pass the array elements onto the various programs config_eth0=( "1.2.3.4/24" "some voodoo" ) becomes ifconfig eth0 1.2.3.4/24 ifconfig eth0 some voodoo We also do the same for iproute2 which has a very comples language structure. We also do this for most of the helper programs that we use - vlan, bridging, wireless just to name a few. Do we want variables for every single possibility? The beauty with the array structure is that it allows the user to define a sequence of commands to send to a helper. The issue with the array structure is that it is bash and we strive to support non bash shells hence the discussion. Oh yes, and transparently supporting the bash config where possible. > Of course, that's still assuming the folks actually doing the baselayout2 > work (you, and I'm not sure how many others working with you) ultimately > decide that it's worth the trouble to change. I do honestly believe from > a user perspective it'll be easier to maintain and thus more trouble-free > if an individual values setup is ultimately chosen, but it's certainly > more work to setup from an implementation perspectiv, and very pointedly, > I'm not the one doing that work, so it's very easy for me to sit here and > get all fancy about how it "should" be done. =8^) IOW, it's very much > your call. You just asked for opinions and I'm happily giving mine. =8^) Well, someone else will have to do that as I sure won't. Thanks Roy -- gentoo-dev@gentoo.org mailing list