1 |
Hello, |
2 |
|
3 |
On Tue, 2009-05-12 at 10:40 +0200, Michael Haubenwallner wrote:< |
4 |
> If there is a different place for requirement discussion of Gentoo |
5 |
> specific GSoC projects, please tell, and sorry for bothering here then. |
6 |
|
7 |
There is another mailing list, but i am sure it doesn't get to as much |
8 |
dev's as this one gets. |
9 |
|
10 |
> |
11 |
> On Mon, 2009-05-04 at 22:01 +0100, Sérgio Almeida wrote: |
12 |
> > Here are the main interest ideas: |
13 |
> > * actions can be run system-wide and per-user: |
14 |
> > # action user moo |
15 |
> > # action system moo |
16 |
> |
17 |
> Are there any thoughts to support something more fine granular settings |
18 |
> than system and user? |
19 |
> |
20 |
|
21 |
Indeed, user is not "for all the users". It's an action that can be run |
22 |
by the users to change it's own settings without touching the system's |
23 |
fallback default. |
24 |
|
25 |
> What I'm after: |
26 |
> We are developing multiple source projects with multiple release |
27 |
> branches on the same host here. These projects do have some script to |
28 |
> set up the project specific environment. One os-user is working on |
29 |
> multiple projects or branches, entering a project's environment by |
30 |
> sourcing its environment script. |
31 |
> |
32 |
> Naturally, these projects do have different requirements to - for |
33 |
> example - the java-vm version. The project admin needs to select the |
34 |
> java-vm on a per-project basis, and does want to use the system-vm as |
35 |
> fallback, never wants to use the user-vm. |
36 |
> |
37 |
> With current eselect (and java-config-2), this would be something like |
38 |
> setting $HOME on the per-project basis - or not using java-config at |
39 |
> all. |
40 |
> |
41 |
> Would it make sense to explicitly set the system-vm (whatever version it |
42 |
> is or will be changed to), while leaving it unset would fall back to the |
43 |
> user-vm? |
44 |
|
45 |
That's the point of the uselect tool. Per-System settings, Per-User |
46 |
settings (2 different ssh sessions of the same user can still have |
47 |
different environment settings too). |
48 |
|
49 |
I work as a sysadmin and manage mainly multi-user gentoo environments |
50 |
where people develop calculus c/python/fortran/R/whatever code using |
51 |
wathever utilities we can imagine. Everytime a new project is beeing |
52 |
done people need to set the environment variables themselves when they |
53 |
are kind enough not to ask me. That's mainly the whole purpose of this |
54 |
uselect tool, easy multi user environments managing. |
55 |
|
56 |
> |
57 |
> More toughts? |
58 |
> |
59 |
> Thanks! |
60 |
|
61 |
I Thank you! |
62 |
|
63 |
> |
64 |
> /haubi/ |
65 |
|
66 |
I would be glad if developers from the *-config utilities could post |
67 |
here and say what their utilities can do that eselect is/was incapable |
68 |
of doing and also the reason why their tools were created for us to find |
69 |
a way that a new "universal select tool" can gather all of *-config |
70 |
features with somthing like these proposed modules. |
71 |
|
72 |
Cheers, |
73 |
Sérgio |
74 |
-- |
75 |
Sérgio Almeida <mephx.x@×××××.com> |
76 |
mephx @ freenode |