From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1I6iR4-00076h-BR for garchives@archives.gentoo.org; Fri, 06 Jul 2007 07:41:02 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l667euiv008035; Fri, 6 Jul 2007 07:40:56 GMT Received: from smtp-gw5.mailanyone.net (smtp-gw5.mailanyone.net [208.70.128.56]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l667etD6008030 for ; Fri, 6 Jul 2007 07:40:56 GMT Received: from mailanyone.net by smtp-gw5.mailanyone.net with esmtpsa (TLSv1:RC4-MD5:128) (MailAnyone extSMTP jalbertosl) id 1I6iQx-0002AE-8K for gnap-dev@lists.gentoo.org; Fri, 06 Jul 2007 02:40:55 -0500 Subject: Re: [gnap-dev] Some patches for gnap From: =?ISO-8859-1?Q?jos=E9?= Alberto =?ISO-8859-1?Q?Su=E1rez_L=F3pez?= To: gnap-dev@lists.gentoo.org In-Reply-To: <59506.130.230.11.107.1183640031.squirrel@my.bawue.net> References: <59506.130.230.11.107.1183640031.squirrel@my.bawue.net> Content-Type: text/plain; charset=utf-8 Date: Fri, 06 Jul 2007 09:40:46 +0200 Message-Id: <1183707646.27777.15.camel@supercoco> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo GNAP development X-BeenThere: gnap-dev@gentoo.org Reply-to: gnap-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: da66d790-623d-497f-85c0-ee07386b3ca8 X-Archives-Hash: e321754e0592807dbc765c6582b87b96 El jue, 05-07-2007 a las 15:53 +0300, Philipp Riegger escribi=C3=B3: > Hi! >=20 > I wanted to send the patches for gnap i made so far. I don't know what i > screwed up, but somehow they do not apply cleanly. I send them anyway for > review, if anybody wants i can send my current gnap_* scripts or recreate > working patches. kingtaco told me infra have the new machine, so i hope to have our new home soon, so all of us can use the repo to work together and fast. > I will send the patcehs as replies to this email (since they are mostly > for review). i will review them soon as possible, so can be great jaervousz and the resto do it too. > 01-split-gnap_make.patch > 02-split-gnap_overlay.patch > 03-split-gnap_remaster.patch >=20 > Theese first 3 patches take the common stuff (functions, constants) from > the gnap_* scripts and put it into gnap_shared.sh >=20 > Note: > 1) There are 2 gnap_shared.sh so far, one in the src and one in the toos > directory of the gnap svn tree. This should maybe be changed... shoudl be > 2) The gnap_* scripts do 'source "gnap_shared.sh"', which is probably not > good. In which directory will we put gnap_shared.sh? at moment "/usr/lib/gnap" [...] > 08-namespace-gnap_shared.patch >=20 > This cleanes up the namespace, all variables that are used as input > parameters in gnap_shared.sh are prefixed with GNAP_ to get a clean usage > of the namespace. More to that later. great [...] > Ok, so far, so good. What's next? >=20 > 1) Configuring gnap >=20 > At the moment configuring gnap_make (at which i concentrate so far) is > quite a mess. We have default parameters (in gnap_shared.sh), we have > catalyst.conf and commons.conf which we simply source, we have command > line options. At the moment this means the following: >=20 > Default options are set first, then they are overwritten by command line > options, which are overwritten by common.conf, ehich are overwritten by > catalyst.conf. >=20 > This is not really clean. For example, we use CATALYST_TEMP_DIR in > common.conf, catalyst uses store_dir in catalyst.conf. This is redundant > and does not make it clean. The default common.conf also defines > CATALYST_CONF (which might be broken because i renamed it, i have to > check), but that means that the command line option for specifying > catalyst.conf does not work if this is not commented out. >=20 > So... do we want to change this? I would like something like: >=20 > We can use variables from the environment. This will only be valid for > GNAP_* variables, so we have a clear namespace and it enables people to > set default variables. I'm not sure, how much this will be needed/used, > but it sounds like an interesting feature. The catalyst.conf is only used > for catalyst configuration (interaction between gnap and catalyst), > therefore it does never make sense to overwrite information given there. >=20 > Default options < environment < common.conf < command line options. >=20 > This would be my prefered way of configuring gnap, where variables from > sources more right overwrite variables from sources more left. i like the idea, work on it and tell me. I prefer as less config files to edit better. > 2) gnap_make feature: pretend >=20 > I'd like a --pretend feature for gnap_make which lets it just create the > configuration files for catalyst and the source files (portage tree, from > tree snapsht and overlays). This might be useful for test runs, > development and usage of catalyst features gnap does not support. This > could be implemented by simply overwriting CATALYST_BIN with "echo > $CATALYSY_BIN", if 1) from above is clear. i prefer to mantain gnap simple as possible, Really some catalyst option is so usefull to use it alone? non-implemented-catalyst options are sufficent usefull to implement them in gnap_make? > 3) gnap_make feature: improved overlay handling >=20 > The overlay handling of gnap_make is some kind of bug, i think. If you > don't take care, Manifests are broken. Therefore i want to change it that > packages (directories in which ebuilds are) are first deleted from the > tree and metadata/cache if they exist, before new ones from overlays are > added. This should be easy to understand, since people usually don't need > stuff from the tree anymore if they use an overlay for a specific package= . To improve is ever good :) > 4) some small stuff >=20 > At the moment, if there is a choice (Overwrite/Append, Yes/No) only one > possibility is checked and the other is assumed, if the one is not given. > I'd like to change this to something like "It is asked in a loop until a > valid option is given." >=20 > There is a function gwarn, writes to stderr. It is used in some places > where ginfo would make more sence, if it would exist. I'd like to > implement and use this. for example? > That's all i wanted to say about the gnap_scripts at the moment. you say a lot :) nice job -- gnap-dev@gentoo.org mailing list