Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

["Sérgio Almeida" <mephx.x@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5977 bytes --]

Michael,

> Eventually, we should pass something like "-Dhostname=superhost" as
> cmdline parameter to uselect...
> 

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.
> 

Agreed, it was just an "easy to read" example. Will adopt {} for those.

> 
> I do have something like this content-syntax in mind for .uselect (or
> eventually some .uprofile) file:
> 
> 8<8<8<
> version "0.1"
> 
> include "path/to/another/uselect/file"
> 
> profile "generic solaris" {
>   module A actionAX "valueAX1" "valueAX2"
>   module B actionBX "valueBX1" "valueBX2
> }
> 
> profile "generic host" {
>   module C actionCX "valueCX1"
> }
> 
> profile "superhost" {
>   inherit profile "generic solaris"
>   inherit profile "generic host"
>   module C actionCX "newvalueCX1"
>   module A actionAX "newvalueAX1" "newvalueAX2"
>   module D actionDY "valueBY1" "valueBY2"
> }
> 
> profile "generic user" {
>   module E actionEX "valueEX1"
> }
> 
> profile "user haubi" {
>   inherit profile "generic user"
>   module F actionFX "valueFX1"
> }
> 
> profile "any user on superhost" {
>   module G actionGX "valueGX1"
> }
> 
> profile "fallback host" {
>   inherit profile "generic host"
>   module A actionAX "valueAX1" "valueAX2"
> }
> 
> activation "superhost activation" {
>   in category "host"
>   on fallback level 0
>   when $hostname matches string "superhost"
>   activate profile "superhost"
> }
> 
> 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"
> }
> 
> activation "haubi" {
>   in category "user"
>   on fallback level 1
>   when $username matches string "haubi"
>   activate profile "user haubi"
> }
> 
> activation "gentoo host" {
>   in category "host"
>   on fallback level 1
>   when $hostname matches regex ".*\.gentoo\.org"
>   activate profile "fallback host"
> }
> >8>8>8
> 
> I'm not sure to have an ascending "fallback level" or descending
> "priority" value, but both should allow for negative integer values.
> 

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".
> 

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=something 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.
> 
> And I'm thinking of something like this commandline:
> $ uselect \
>   --categories host,user \
>   --define hostname=`hostname` \
>   --define username=`whoami`
> 
> > 
> > Remember that profile creation/storing/managing should be automatic and
> > nothing would need to be written by hand.
> 
> 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.
> 

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.
> 
> Sounds interesting...
> 
> > 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.
> 
> Indeed, yes.
> 
> > > Ha! This kind of inheritance tree could be a solution for my long
> > > standing bug here to simplify our way too complex environment script...
> > > 
> > 
> > This is a basic idea from softenv so it has has it's place into uselect.
> 
> Don't know softenv. Found http://www.teragrid.org/userinfo/softenv/
> Do you mean this one?
> 

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.
> 
> That's indeed the question.
> 
> > Mmmm... As you wrote I realized: Complain if module versions are
> > different is not a bad idea at all... 
> 
> Indeed, not only the configuration needs to be versioned, but the
> modules too.
> 

On to-do!

> > 
> > Why would we need more that one profile file per project/folder anyway?
> 
> Might not be necessary, at least not for non-profiled uselect.
> 
> > > Uh, so many strange ideas!
> > > More of them?
> > 
> > Keep 'em coming! Thanks!
> 
> Well, you have asked ;)
> 
> /haubi/


Thanks again.

Cheers,
Sérgio
-- 
Sérgio Almeida <mephx.x@gmail.com>
mephx @ freenode

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]