| 1 |
On Tue, 2009-05-12 at 21:45 +0100, Sérgio Almeida wrote: |
| 2 |
|
| 3 |
> How about having the profile switch automatic whenever |
| 4 |
> you call "uselect something" getting the current profile settings from |
| 5 |
> current dir's .uselect folder? |
| 6 |
|
| 7 |
Yeah, this indeed could work! |
| 8 |
|
| 9 |
But there is one restriction: |
| 10 |
This .uselect folder must be able to be checked in into some VCS, so it |
| 11 |
should not contain symlinks, but plain (text?) files only. |
| 12 |
We also want to use this on Windows based filesystems where symlinks |
| 13 |
don't work at all. |
| 14 |
|
| 15 |
Ohw, I do have another requirement: |
| 16 |
We do check-out/compile/develop/run/test the same package on different |
| 17 |
hosts and platforms. Each of these hosts might require slightly |
| 18 |
different settings. ATM, the package's environment script handles this |
| 19 |
by acting differently based on `hostname` and `uname` or "${chost}". |
| 20 |
Ohw, it even does different settings based on the username (`id -un` or |
| 21 |
`whoami`), because in production these projects usually run under a |
| 22 |
specific user with less restrictive settings than for developers. |
| 23 |
|
| 24 |
What if there is some hierarchy in .uselect/ much like the profiles in |
| 25 |
gentoo-x86 tree, using some kind of 'parent' files to inherit/override |
| 26 |
settings for this one project, where 'parent' can contain something like |
| 27 |
$(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)? |
| 28 |
|
| 29 |
I'm unsure if managing different settings based on hostname, uname/chost |
| 30 |
and username (the inheritance tree) is uselect's job. It eventually |
| 31 |
should optionally listen to some cmdline-parameter or environment- |
| 32 |
variable where to look for the uselect settings instead, which could be |
| 33 |
stored and regenerated using such profile hierarchy mechanism/utility. |
| 34 |
Or even the whole uselect settings optionally come from stdin (and go to |
| 35 |
stdout), to be managed/stored within that profile hierarchy. |
| 36 |
|
| 37 |
Ha! This kind of inheritance tree could be a solution for my long |
| 38 |
standing bug here to simplify our way too complex environment script... |
| 39 |
|
| 40 |
Ah, don't forget to put a version number as the very first value into |
| 41 |
the uselect settings, to avoid backwards compatibility issues in the |
| 42 |
future. And when uselect settings can be read from stdin (stored in |
| 43 |
simple text files), this version number could occur multiple times |
| 44 |
there, as the stored files simply will be concatenated. And subsequent |
| 45 |
values might override previous ones then. |
| 46 |
|
| 47 |
Uh, so many strange ideas! |
| 48 |
More of them? |
| 49 |
|
| 50 |
Thanks! |
| 51 |
|
| 52 |
/haubi/ |
| 53 |
-- |
| 54 |
Michael Haubenwallner |
| 55 |
Gentoo on a different level |
Archives