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-39-garchives=archives.gentoo.org@gentoo.org>)
id 1I6pQX-0001dX-0W
for garchives@archives.gentoo.org; Fri, 06 Jul 2007 15:08:57 +0000
Received: from robin.gentoo.org (localhost [127.0.0.1])
by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l66F8sgv007343;
Fri, 6 Jul 2007 15:08:54 GMT
Received: from mail.bawue.net (phoenix.bawue.net [193.7.176.60])
by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l66F8stC007326
for <gnap-dev@lists.gentoo.org>; Fri, 6 Jul 2007 15:08:54 GMT
Received: from my.bawue.net (imap.bawue.net [193.7.176.64])
by mail.bawue.net (Postfix) with ESMTP id 65CDFB955C
for <gnap-dev@lists.gentoo.org>; Fri, 6 Jul 2007 17:08:20 +0200 (CEST)
Received: from 130.230.11.107
(SquirrelMail authenticated user stoile)
by my.bawue.net with HTTP;
Fri, 6 Jul 2007 18:08:20 +0300 (EEST)
Message-ID: <45178.130.230.11.107.1183734500.squirrel@my.bawue.net>
In-Reply-To: <1183707646.27777.15.camel@supercoco>
References: <59506.130.230.11.107.1183640031.squirrel@my.bawue.net>
<1183707646.27777.15.camel@supercoco>
Date: Fri, 6 Jul 2007 18:08:20 +0300 (EEST)
Subject: Re: [gnap-dev] Some patches for gnap
From: "Philipp Riegger" <lists@anderedomain.de>
To: gnap-dev@lists.gentoo.org
User-Agent: SquirrelMail/1.4.2
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
Content-Type: text/plain;charset=iso-8859-1
X-Priority: 3
Importance: Normal
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id l66F8sh2007343
X-Archives-Salt: 73580f84-f8d9-4ed4-b2cd-f54f41b5a154
X-Archives-Hash: df542b06c2b38aae0a23e6cfdd20c8cf
jos=E9 Alberto Su=E1rez L=F3pez wrote:
> 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.
Nice. With this change, are you also switching to svn or soemthing like
that or changing the gnap repository layout? Making a difference between
gnap_make and the other scripts seems rather artificial, since they are
sharing code now.
>> Note:
>> 1) There are 2 gnap_shared.sh so far, one in the src and one in the to=
os
>> directory of the gnap svn tree. This should maybe be changed...
>
> shoudl be
Where do you want to have it?
>> 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"
Seems to make the most sense, i'll change that.
>> 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
It's not 100% clean so far, i did not work on variables in gnap_overlay
and gnap_remaster so far, i also forgot to check which implications this
has on the config files.
>> 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 li=
ne
>> options, which are overwritten by common.conf, ehich are overwritten b=
y
>> 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 redunda=
nt
>> 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 t=
o
>> 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 ther=
e.
>>
>> Default options < environment < common.conf < command line options.
>>
>> This would be my prefered way of configuring gnap, where variables fro=
m
>> 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.
The easiest way to implement this would be:
We use ${:-} or ${:=3D} (i have to understand the difference between them=
)
for default parameters, parse the command line for the first time only
extracting parameters concerning external config files or -h, parse thees=
e
config files (we have them or default config files), order will be
common.conf and then catalyst.conf (so common.conf can overwrite the
variable saying where to find catalyst.conf), we parse the command line
options again and use all the info given there to set/overwrite variables.
Advantages:
- No additional variables needed
- Quite easy change
- Should give us what we want
- No need for a config file parser
Disadvantages:
- Well... common.conf and catalyst.conf can overwrite lots of things, we
never check which config file is allowed to overwrite what. But if
somebody does strange things there, it's not our fault, i think
>> 2) gnap_make feature: pretend
>>
>> I'd like a --pretend feature for gnap_make which lets it just create t=
he
>> 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 optio=
n
> is so usefull to use it alone? non-implemented-catalyst options are
> sufficent usefull to implement them in gnap_make?
Hmm, all the reasons why i thought this might be a good idea are only
minor. So... i'll move that off my todo list until i find a valid use cas=
e
for it.
>> 3) gnap_make feature: improved overlay handling
[...]
> To improve is ever good :)
An alternative would be to introduce overlay handling to catalyst, but i
think, we don't want that. :-)
>> 4) some small stuff
>>
>> At the moment, if there is a choice (Overwrite/Append, Yes/No) only on=
e
>> 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."
Any comments on this?
Examples:
gconfirm() {
if [[ "${FORCEYES}" -eq 1 ]]; then
gwarn "${*} forced to yes"
else
read -ep " ${W}*${N} ${*} [N]: " answer
if [[ "${answer}" !=3D 'y' && "${answer}" !=3D 'Y' ]]; th=
en
if [[ -n "${GNAP_TEMPDIR}" ]]; then
cleanup
fi
echo "${GNAP_PRODUCT} aborted !"
exit 2
fi
fi
}
what if the user mixes up for example german and us keyboard layout, want=
s
to say y but gets z instead?
if [[ -f "${GNAP_LOGPREFIX}.out" || -f "${GNAP_LOGPREFIX}.err" ]]; then
if [[ "${FORCEYES}" -ne 1 ]]; then
read -ep " ${W}*${N} Logfile(s) already exists.
Append/Overwrite
[A]: " \
answer
if [[ "${answer}" =3D=3D 'o' || "${answer}" =3D=3D 'O' ]]=
; then
rm "${GNAP_LOGPREFIX}.out" "${GNAP_LOGPREFIX}.err=
"
fi
fi
fi
Same here, i cannot think of keymap issues but peope sometimes hit the
wrong button. Should we have the questions in a loop until they are
answered correctly?
>> 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?
gwarn 'The following targets will be called:'
gwarn "${TARGETLIST}"
>> That's all i wanted to say about the gnap_scripts at the moment.
>
> you say a lot :)
Hmm... is that good or bad? :)
> nice job
Thanks, unfortunately not what i applied for. :-(
See you,
Philipp
--=20
gnap-dev@gentoo.org mailing list