Gentoo Archives: gnap-dev

From: "josé Alberto Suárez López" <bass@g.o>
To: gnap-dev@l.g.o
Subject: Re: [gnap-dev] Some patches for gnap
Date: Fri, 06 Jul 2007 07:41:02
Message-Id: 1183707646.27777.15.camel@supercoco
In Reply to: [gnap-dev] Some patches for gnap by Philipp Riegger
El jue, 05-07-2007 a las 15:53 +0300, Philipp Riegger escribió:
> Hi! > > 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 > > Theese first 3 patches take the common stuff (functions, constants) from > the gnap_* scripts and put it into gnap_shared.sh > > 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 > > 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? > > 1) Configuring gnap > > 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: > > 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. > > 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. > > So... do we want to change this? I would like something like: > > 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. > > Default options < environment < common.conf < command line options. > > 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 > > 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 > > 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 > > 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." > > 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@g.o mailing list

Replies

Subject Author
Re: [gnap-dev] Some patches for gnap Philipp Riegger <lists@××××××××××××.de>