Gentoo Archives: gentoo-dev

From: "Sérgio Almeida" <mephx.x@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool
Date: Tue, 12 May 2009 14:33:15
Message-Id: 1242138772.3438.74.camel@thedude
In Reply to: Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool by Michael Haubenwallner
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

Replies

Subject Author
Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool Michael Haubenwallner <haubi@g.o>