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 1IlUU4-0004GD-7o for garchives@archives.gentoo.org; Fri, 26 Oct 2007 19:04:40 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.1/8.14.0) with SMTP id l9QJ36vR024306; Fri, 26 Oct 2007 19:03:06 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.1/8.14.0) with ESMTP id l9QJ0sR8021790 for ; Fri, 26 Oct 2007 19:00:55 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8118B6485D for ; Fri, 26 Oct 2007 19:00:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 required=5.5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhgYjr8Mtj1P for ; Fri, 26 Oct 2007 19:00:47 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 5E5DC642A6 for ; Fri, 26 Oct 2007 19:00:46 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IlUP2-0004DP-CA for gentoo-dev@gentoo.org; Fri, 26 Oct 2007 18:59:28 +0000 Received: from ip68-230-96-73.ph.ph.cox.net ([68.230.96.73]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 18:59:28 +0000 Received: from 1i5t5.duncan by ip68-230-96-73.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Oct 2007 18:59:28 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Opinions Wanted - Arrays again :) Date: Fri, 26 Oct 2007 18:57:25 +0000 (UTC) Message-ID: 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> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-96-73.ph.ph.cox.net User-Agent: Pan/0.132 (Waxed in Black) Sender: news X-Archives-Salt: aac93de2-df65-4e57-884f-a3c7e5390b9c X-Archives-Hash: b6365b438cf4384bdc990016f5c52015 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. Besides, the idea is that the vars should be almost self-documenting for at least the "simple" setups, so while there'd certainly be a conversion necessary, for those "simple" setups, it should be as easy to explain that as it will be/is to explain the rules for converting to arrays and have them get it right (said as one who has done the conversion to the present baselayout-2 format and screwed up something dumb in the process). Converting the somewhat "magic" array from one form to another, due to that "magic", is going to be more error prone than converting to vars of the type Gentoo users already use every day, each with a single defined purpose, no fancy format necessary. That's for the "simple" setups. The more complex setups by definition should have folks that understand those setups well enough to do the conversion without major issue, since they pretty much had to in ordered to create them in the first place. 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. 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^) Of course, as I'm already on baselayout2, I'll be bug testing whatever is ultimately decided. =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@gentoo.org mailing list