Hello, On Tue, 2009-05-12 at 10:40 +0200, Michael Haubenwallner wrote:< > If there is a different place for requirement discussion of Gentoo > specific GSoC projects, please tell, and sorry for bothering here then.
There is another mailing list, but i am sure it doesn't get to as much dev's as this one gets. > > On Mon, 2009-05-04 at 22:01 +0100, Sérgio Almeida wrote: > > Here are the main interest ideas: > > * actions can be run system-wide and per-user: > > # action user moo > > # action system moo > > Are there any thoughts to support something more fine granular settings > than system and user? > Indeed, user is not "for all the users". It's an action that can be run by the users to change it's own settings without touching the system's fallback default. > What I'm after: > We are developing multiple source projects with multiple release > branches on the same host here. These projects do have some script to > set up the project specific environment. One os-user is working on > multiple projects or branches, entering a project's environment by > sourcing its environment script. > > Naturally, these projects do have different requirements to - for > example - the java-vm version. The project admin needs to select the > java-vm on a per-project basis, and does want to use the system-vm as > fallback, never wants to use the user-vm. > > With current eselect (and java-config-2), this would be something like > setting $HOME on the per-project basis - or not using java-config at > all. > > Would it make sense to explicitly set the system-vm (whatever version it > is or will be changed to), while leaving it unset would fall back to the > user-vm? That's the point of the uselect tool. Per-System settings, Per-User settings (2 different ssh sessions of the same user can still have different environment settings too). I work as a sysadmin and manage mainly multi-user gentoo environments where people develop calculus c/python/fortran/R/whatever code using wathever utilities we can imagine. Everytime a new project is beeing done people need to set the environment variables themselves when they are kind enough not to ask me. That's mainly the whole purpose of this uselect tool, easy multi user environments managing. > > More toughts? > > Thanks! I Thank you! > > /haubi/ I would be glad if developers from the *-config utilities could post here and say what their utilities can do that eselect is/was incapable of doing and also the reason why their tools were created for us to find a way that a new "universal select tool" can gather all of *-config features with somthing like these proposed modules. Cheers, Sérgio -- Sérgio Almeida <meph...@gmail.com> mephx @ freenode
