| 1 |
If there is a different place for requirement discussion of Gentoo |
| 2 |
specific GSoC projects, please tell, and sorry for bothering here then. |
| 3 |
|
| 4 |
On Mon, 2009-05-04 at 22:01 +0100, Sérgio Almeida wrote: |
| 5 |
> Here are the main interest ideas: |
| 6 |
> * actions can be run system-wide and per-user: |
| 7 |
> # action user moo |
| 8 |
> # action system moo |
| 9 |
|
| 10 |
Are there any thoughts to support something more fine granular settings |
| 11 |
than system and user? |
| 12 |
|
| 13 |
What I'm after: |
| 14 |
We are developing multiple source projects with multiple release |
| 15 |
branches on the same host here. These projects do have some script to |
| 16 |
set up the project specific environment. One os-user is working on |
| 17 |
multiple projects or branches, entering a project's environment by |
| 18 |
sourcing its environment script. |
| 19 |
|
| 20 |
Naturally, these projects do have different requirements to - for |
| 21 |
example - the java-vm version. The project admin needs to select the |
| 22 |
java-vm on a per-project basis, and does want to use the system-vm as |
| 23 |
fallback, never wants to use the user-vm. |
| 24 |
|
| 25 |
With current eselect (and java-config-2), this would be something like |
| 26 |
setting $HOME on the per-project basis - or not using java-config at |
| 27 |
all. |
| 28 |
|
| 29 |
Would it make sense to explicitly set the system-vm (whatever version it |
| 30 |
is or will be changed to), while leaving it unset would fall back to the |
| 31 |
user-vm? |
| 32 |
|
| 33 |
More toughts? |
| 34 |
|
| 35 |
Thanks! |
| 36 |
|
| 37 |
/haubi/ |
| 38 |
-- |
| 39 |
Michael Haubenwallner |
| 40 |
Gentoo on a different level |
Archives