Re: [gnap-dev] Some patches for gnap

["josé Alberto Suárez López" <bass@gentoo.org>]

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@gentoo.org mailing list