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

[Michael Haubenwallner <haubi@gentoo.org>]

On Tue, 2009-05-12 at 21:45 +0100, Sérgio 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/
-- 
Michael Haubenwallner
Gentoo on a different level