From: "Philipp Riegger" <lists@anderedomain.de>
To: gnap-dev@lists.gentoo.org
Subject: [gnap-dev] Some patches for gnap
Date: Thu, 5 Jul 2007 15:53:51 +0300 (EEST) [thread overview]
Message-ID: <59506.130.230.11.107.1183640031.squirrel@my.bawue.net> (raw)
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.
I will send the patcehs as replies to this email (since they are mostly
for review).
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...
2) The gnap_* scripts do 'source "gnap_shared.sh"', which is probably not
good. In which directory will we put gnap_shared.sh?
04-feature-gnap_make-T.patch
05-festure-gnap_overlay-T.patch
06-feature-gnap_remaster-T.patch
07-split-make_tempdir.patch
After i created the first patch (with which it is possible to specify a
temp directory for gnap_make) i did the same for the other scripts and put
the logic in gnap_shared.sh finally. For the moment this is to prevent
using too small temp directories, later i want to create an option to
prevent deleting special files that they can be used after a gnap run. I
already talked about this.
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.
09-cleanup-gnap_make.patch
Some small fixes for gnap_make.
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.
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.
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.
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.
That's all i wanted to say about the gnap_scripts at the moment.
Philipp
--
gnap-dev@gentoo.org mailing list
next reply other threads:[~2007-07-05 13:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-05 12:53 Philipp Riegger [this message]
2007-07-05 13:03 ` [gnap-dev] 01-split-gnap_make.patch Philipp Riegger
2007-07-05 13:05 ` [gnap-dev] 03-split-gnap_remaster.patch Philipp Riegger
2007-07-05 13:06 ` [gnap-dev] 04-feature-gnap_make-T.patch Philipp Riegger
2007-07-05 13:07 ` [gnap-dev] 05-festure-gnap_overlay-T.patch Philipp Riegger
2007-07-05 13:08 ` [gnap-dev] 06-feature-gnap_remaster-T.patch Philipp Riegger
2007-07-05 13:09 ` [gnap-dev] 07-split-make_tempdir.patch Philipp Riegger
2007-07-05 13:10 ` [gnap-dev] 08-namespace-gnap_shared.patch Philipp Riegger
2007-07-05 13:11 ` [gnap-dev] 09-cleanup-gnap_make.patch Philipp Riegger
2007-07-06 7:40 ` [gnap-dev] Some patches for gnap josé Alberto Suárez López
2007-07-06 15:08 ` Philipp Riegger
2007-07-09 7:13 ` josé Alberto Suárez López
2007-07-12 23:49 ` Philipp Riegger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59506.130.230.11.107.1183640031.squirrel@my.bawue.net \
--to=lists@anderedomain.de \
--cc=gnap-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox