From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M4GZO-0000Hv-Ft for garchives@archives.gentoo.org; Wed, 13 May 2009 15:40:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 02AA3E02E8; Wed, 13 May 2009 15:40:33 +0000 (UTC) Received: from mail-bw0-f175.google.com (mail-bw0-f175.google.com [209.85.218.175]) by pigeon.gentoo.org (Postfix) with ESMTP id 9447AE02E8 for ; Wed, 13 May 2009 15:40:32 +0000 (UTC) Received: by bwz23 with SMTP id 23so709024bwz.34 for ; Wed, 13 May 2009 08:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=ZAYocdzYeWVpiTJiW1kY9PI63Ib68Q0p5rDQdUMkuAE=; b=tKAY7P0k8OOYLeT5Hij9Wtdt3jbX4tQoFBru2dDoP7XnWiaanJ9YtXC7nmW2fbJ1zy g46TrJczlGiFf4/n62pkf0RYbGTdnR8R5KhoCgCD4DCqlL+IBc3oI6s8sgS/xBFFNPG/ SZujO9cVwxdyMztGrf2Ho+SvQUQiIKOWPHZsw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=MwHfbaZo3j4lePgX2WuTHQeEDEn1MybJyT6lLzzAGAL0GhPJQSynDb6WKU66BTMdxt YQQHiyujURVUmnHXYB/PpSFIkfBQyOwp0dJJNheDG/PB+/TmXhVLwowxJRSL5nC8RQpB C/k+TKge/K4swPSiCEGnAJUAGACPqpeS14z4c= Received: by 10.204.66.17 with SMTP id l17mr1056372bki.51.1242229231872; Wed, 13 May 2009 08:40:31 -0700 (PDT) Received: from ?192.168.127.16? (magdalene.ist.utl.pt [193.136.161.161]) by mx.google.com with ESMTPS id e17sm142592fke.13.2009.05.13.08.40.31 (version=SSLv3 cipher=RC4-MD5); Wed, 13 May 2009 08:40:31 -0700 (PDT) Subject: Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool From: =?ISO-8859-1?Q?S=E9rgio?= Almeida To: gentoo-dev@lists.gentoo.org In-Reply-To: <1242199689.19525.52.camel@salomon-22> References: <1241470894.6119.80.camel@thedude> <1242117631.31723.41.camel@sapc154.salomon.at> <1242138772.3438.74.camel@thedude> <1242146078.9407.13.camel@sapc154.salomon.at> <1242161118.3438.85.camel@thedude> <1242199689.19525.52.camel@salomon-22> Content-Type: text/plain; charset="UTF-8" Date: Wed, 13 May 2009 16:40:29 +0100 Message-Id: <1242229229.23678.41.camel@thedude> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d13d87ab-2993-44cb-ba5a-cece377547b8 X-Archives-Hash: 512a9fb9fd2c5b72eb8bef914b72484c Michael, > Yeah, this indeed could work! >=20 > But there is one restriction: > This .uselect folder must be able to be checked in into some VCS, so it > should not contain symlinks, but plain (text?) files only. > We also want to use this on Windows based filesystems where symlinks > don't work at all. >=20 Do we really need more than one file?=20 > Ohw, I do have another requirement: > We do check-out/compile/develop/run/test the same package on different > hosts and platforms. Each of these hosts might require slightly > different settings. ATM, the package's environment script handles this > by acting differently based on `hostname` and `uname` or "${chost}". > Ohw, it even does different settings based on the username (`id -un` or > `whoami`), because in production these projects usually run under a > specific user with less restrictive settings than for developers. >=20 Checklist: * Hostname * Uname * {$chost} Mmm... Maybe we can simplify this with a parameter like: # eval something eval "hostname" "superhost" what to do # end something Then if command "hostname" outputs "superhost" we know "what-to-do".=20 This way it would get ultra versatile. > What if there is some hierarchy in .uselect/ much like the profiles in > gentoo-x86 tree, using some kind of 'parent' files to inherit/override > settings for this one project, where 'parent' can contain something lik= e > $(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)? >=20 Would this really be necessary? We can define hierarchy into a single .uselect file. Even the use of folders (folder .uselect/) isn't necessary. I think a single file can handle all this... Lets see an example: # profile something version '0.1' do this 1 do that 1 # eval hostname eval "hostname" "supermachina" do that 2 # this should override the prev. value # eval whomai <- inheritance inside eval hostname eval "whoami" "mephx" do more of this do more of that # end whoami # end hostname # eval uname eval "uname" "Linux" do this 3 <- override the overridden =3D) # end uname The actions to be done like "do this 3" are a simple call to uselect using module "do" and action "this" with "3" as parameters. Remember that profile creation/storing/managing should be automatic and nothing would need to be written by hand. By other words, create a basic profile automatically using your currently running settings and then alter the profile with the util to add constrains to it. Remember that all the machines that this profile is read would need to have the same uselect modules into it's /usr/share/uselect/modules or similar. > I'm unsure if managing different settings based on hostname, uname/chos= t > and username (the inheritance tree) is uselect's job. It eventually > should optionally listen to some cmdline-parameter or environment- > variable where to look for the uselect settings instead, which could be > stored and regenerated using such profile hierarchy mechanism/utility. > Or even the whole uselect settings optionally come from stdin (and go t= o > stdout), to be managed/stored within that profile hierarchy. >=20 > Ha! This kind of inheritance tree could be a solution for my long > standing bug here to simplify our way too complex environment script... >=20 This is a basic idea from softenv so it has has it's place into uselect. The question now is, bloat it all into uselect or create a uprofile util? I like the idea of having to use only uselect for basic profiling and using uprofile for further managing. > Ah, don't forget to put a version number as the very first value into > the uselect settings, to avoid backwards compatibility issues in the > future. And when uselect settings can be read from stdin (stored in > simple text files), this version number could occur multiple times > there, as the stored files simply will be concatenated. And subsequent > values might override previous ones then. >=20 Mmmm... As you wrote I realized: Complain if module versions are different is not a bad idea at all...=20 Why would we need more that one profile file per project/folder anyway? > Uh, so many strange ideas! > More of them? >=20 Keep 'em coming! Thanks! Cheers, S=C3=A9rgio