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 1M48sx-0008Hf-JE for garchives@archives.gentoo.org; Wed, 13 May 2009 07:28:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9DFB5E0371; Wed, 13 May 2009 07:28:12 +0000 (UTC) Received: from email.aon.at (WARSL404PIP3.highway.telekom.at [195.3.96.115]) by pigeon.gentoo.org (Postfix) with ESMTP id 27EF9E0371 for ; Wed, 13 May 2009 07:28:12 +0000 (UTC) Received: (qmail 18217 invoked from network); 13 May 2009 07:28:10 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on WARSBL601.highway.telekom.at X-Spam-Level: * Received: from 88-117-58-4.adsl.highway.telekom.at (HELO [10.0.0.1]) ([88.117.58.4]) (envelope-sender ) by smarthub92.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 13 May 2009 07:28:10 -0000 Subject: Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool From: Michael Haubenwallner To: gentoo-dev@lists.gentoo.org In-Reply-To: <1242161118.3438.85.camel@thedude> 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> Content-Type: text/plain; charset=ISO-8859-15 Date: Wed, 13 May 2009 09:28:09 +0200 Message-Id: <1242199689.19525.52.camel@salomon-22> 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.22.3.1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 0bce078f-5fa5-469b-b8d1-cdf7f5689196 X-Archives-Hash: 885153a1ea7faf4714d14633d818090c On Tue, 2009-05-12 at 21:45 +0100, S=E9rgio Almeida wrote: > How about having the profile switch automatic whenever > you call "uselect something" getting the current profile settings from > current dir's .uselect folder? Yeah, this indeed could work! 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. 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. 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 like $(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)? I'm unsure if managing different settings based on hostname, uname/chost 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 to stdout), to be managed/stored within that profile hierarchy. Ha! This kind of inheritance tree could be a solution for my long standing bug here to simplify our way too complex environment script... 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. Uh, so many strange ideas! More of them? Thanks! /haubi/ --=20 Michael Haubenwallner Gentoo on a different level