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 1M7gob-0007vs-UD for garchives@archives.gentoo.org; Sat, 23 May 2009 02:18:26 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C43F7E02DE; Sat, 23 May 2009 02:18:24 +0000 (UTC) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by pigeon.gentoo.org (Postfix) with ESMTP id 6A5A3E02DE for ; Sat, 23 May 2009 02:18:24 +0000 (UTC) Received: by ewy9 with SMTP id 9so2097327ewy.34 for ; Fri, 22 May 2009 19:18:23 -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; bh=/oZ8xi4RfF3uz+wwTwK1LYf7iIWynCXDiGqQmD7hUnc=; b=B0nS8oO1+6vlg5g9G3NRm4sii/KdJdipEH+HzD11uZVSkP9g/1B0oFjhMRJWsXAFwM LezV9+DIdqcUewYDZYVIVS/M1iQ815DZHfTylxs2jIgAa17UX/h1O//JKZefVgHbtitf p7I9lIqvL5ttusylWzy3BKAoKN4moWwuYehjU= 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; b=wuvuWkOf4uTOueRU04jVZyEQqLOAYTE0f2wyoqc7RElFrL6MhLM9u98h0xfclacRIR vXK66dR3HeBw/cuVgRrspkgbosPv011dpyX61JkWxJBPbPTLfEqzvu95CmyCB7tamKfA 3PY8PfsXutAFOGQjB2W8gx+f7VpVoCie341eE= Received: by 10.210.120.17 with SMTP id s17mr1469938ebc.77.1243045103839; Fri, 22 May 2009 19:18:23 -0700 (PDT) Received: from ?10.0.0.2? ([89.180.41.25]) by mx.google.com with ESMTPS id 28sm1700754eyg.54.2009.05.22.19.18.22 (version=SSLv3 cipher=RC4-MD5); Fri, 22 May 2009 19:18:22 -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: <1242385684.26984.200.camel@sapc154.salomon.at> 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> <1242229229.23678.41.camel@thedude> <1242385684.26984.200.camel@sapc154.salomon.at> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fFltAD80gDdOdDy7qDxn" Date: Sat, 23 May 2009 03:18:20 +0100 Message-Id: <1243045100.3909.29.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 X-Archives-Salt: 39e7082f-dc33-4456-b2d0-55809041c165 X-Archives-Hash: 8eedaa89cd311799951bc529dbbbc1f2 --=-fFltAD80gDdOdDy7qDxn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael, > Eventually, we should pass something like "-Dhostname=3Dsuperhost" as > cmdline parameter to uselect... >=20 Didn't want to get into that detail. Afterall `hostname` will always return the same regarding the host therefore it can be retrieved from uselect's engine. > I don't like to have anything interpreted after the usual and well-known > comment-marker, this just feels hackish. >=20 Agreed, it was just an "easy to read" example. Will adopt {} for those. >=20 > I do have something like this content-syntax in mind for .uselect (or > eventually some .uprofile) file: >=20 > 8<8<8< > version "0.1" >=20 > include "path/to/another/uselect/file" >=20 > profile "generic solaris" { > module A actionAX "valueAX1" "valueAX2" > module B actionBX "valueBX1" "valueBX2 > } >=20 > profile "generic host" { > module C actionCX "valueCX1" > } >=20 > profile "superhost" { > inherit profile "generic solaris" > inherit profile "generic host" > module C actionCX "newvalueCX1" > module A actionAX "newvalueAX1" "newvalueAX2" > module D actionDY "valueBY1" "valueBY2" > } >=20 > profile "generic user" { > module E actionEX "valueEX1" > } >=20 > profile "user haubi" { > inherit profile "generic user" > module F actionFX "valueFX1" > } >=20 > profile "any user on superhost" { > module G actionGX "valueGX1" > } >=20 > profile "fallback host" { > inherit profile "generic host" > module A actionAX "valueAX1" "valueAX2" > } >=20 > activation "superhost activation" { > in category "host" > on fallback level 0 > when $hostname matches string "superhost" > activate profile "superhost" > } >=20 > activation "haubi on superhost" { > in category "user" > on fallback level 0 > when $username matches string "haubi" > when $hostname matches string "superhost" > activate profile "any user on superhost" > activate profile "user haubi" > } >=20 > activation "haubi" { > in category "user" > on fallback level 1 > when $username matches string "haubi" > activate profile "user haubi" > } >=20 > activation "gentoo host" { > in category "host" > on fallback level 1 > when $hostname matches regex ".*\.gentoo\.org" > activate profile "fallback host" > } > >8>8>8 >=20 > I'm not sure to have an ascending "fallback level" or descending > "priority" value, but both should allow for negative integer values. >=20 I'm not quite shure if this hierarchy fallback method is the most adequate one. Again, remember that the profiles will be automatically created and manipulation needs to be easy. I guess we can arrange for a better way of managing this. > The selection of one or more profiles is controlled by "activation" > entries, independent for each "category". The order and selection of > categories is done via a commandline argument, fex "--categories". >=20 We are mixing some more complex concepts that don't need to be managed this way. Let's see. Types of Profiles: something.uprofile <- local file profile .uprofile <- folder profile /usr/share/uprofiles/*.uprofile <- template profiles Adding categories to a folder profile is the same as having several file profiles into that directory and load them on demand. Why specify to uselect --categories=3Dsomething when you can "uselelect loadprofile something" (loads .uselect folder profile first, and then overrides settings as specified in something.uprofile). > Profiles are selected when all of the "when" entries (besides "category" > and "fallback level") in "activation {}" do match. > Selected are *all* of the matching profiles in the *lowest* "fallback > level" *only*, which does have at least one matching profile. >=20 > And I'm thinking of something like this commandline: > $ uselect \ > --categories host,user \ > --define hostname=3D`hostname` \ > --define username=3D`whoami` >=20 > >=20 > > Remember that profile creation/storing/managing should be automatic and > > nothing would need to be written by hand. >=20 > Yes, would be fine. When using something like above configuration file > syntax, some GUIding tool would be useful, at least to see which > profiles are selected for specific cmdline args. >=20 Mmm... later feature for more complex profiling. Let us stop now and focus on simple profiling with easy managing. > > 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. >=20 > Sounds interesting... >=20 > > 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. >=20 > Indeed, yes. >=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 > >=20 > > This is a basic idea from softenv so it has has it's place into uselect= . >=20 > Don't know softenv. Found http://www.teragrid.org/userinfo/softenv/ > Do you mean this one? >=20 Indeed. > > 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. >=20 > That's indeed the question. >=20 > > Mmmm... As you wrote I realized: Complain if module versions are > > different is not a bad idea at all...=20 >=20 > Indeed, not only the configuration needs to be versioned, but the > modules too. >=20 On to-do! > >=20 > > Why would we need more that one profile file per project/folder anyway? >=20 > Might not be necessary, at least not for non-profiled uselect. >=20 > > > Uh, so many strange ideas! > > > More of them? > >=20 > > Keep 'em coming! Thanks! >=20 > Well, you have asked ;) >=20 > /haubi/ Thanks again. Cheers, S=C3=A9rgio --=20 S=C3=A9rgio Almeida mephx @ freenode --=-fFltAD80gDdOdDy7qDxn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkoXXOIACgkQQXumuXcKj053HACbBjgNECpoTRoLZQ8TughYuyoC l1AAnjXVzITEpqvCvO/D3/EMnSq8Oz4W =vP9B -----END PGP SIGNATURE----- --=-fFltAD80gDdOdDy7qDxn--