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 <gnap-dev+bounces-38-garchives=archives.gentoo.org@gentoo.org>)
	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 <gnap-dev@lists.gentoo.org>; 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?= <bass@gentoo.org>
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: <mailto:gnap-dev@lists.gentoo.org>
List-Help: <mailto:gnap-dev+help@gentoo.org>
List-Unsubscribe: <mailto:gnap-dev+unsubscribe@gentoo.org>
List-Subscribe: <mailto:gnap-dev+subscribe@gentoo.org>
List-Id: Gentoo GNAP development <gnap-dev.gentoo.org>
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