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

[Sérgio Almeida]

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@×××××.com>
mephx @ freenode