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 ) 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 ; 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 ; 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" To: gnap-dev@lists.gentoo.org User-Agent: SquirrelMail/1.4.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo GNAP development 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