public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Sérgio Almeida" <mephx.x@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool
Date: Tue, 12 May 2009 15:32:52 +0100	[thread overview]
Message-ID: <1242138772.3438.74.camel@thedude> (raw)
In-Reply-To: <1242117631.31723.41.camel@sapc154.salomon.at>

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 <mephx.x@gmail.com>
mephx @ freenode




  reply	other threads:[~2009-05-12 14:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-04 21:01 [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool Sérgio Almeida
2009-05-05  2:30 ` Denis Dupeyron
2009-05-10 22:56 ` Mark Loeser
2009-05-11 19:09   ` Sérgio Almeida
2009-05-12  8:40 ` Michael Haubenwallner
2009-05-12 14:32   ` Sérgio Almeida [this message]
2009-05-12 16:34     ` Michael Haubenwallner
2009-05-12 20:45       ` Sérgio Almeida
2009-05-13  7:28         ` Michael Haubenwallner
2009-05-13 15:40           ` Sérgio Almeida
2009-05-15 11:08             ` Michael Haubenwallner
2009-05-23  2:18               ` Sérgio Almeida
2009-05-26 20:04 ` Tiziano Müller
2009-05-26 20:47   ` Sérgio Almeida

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1242138772.3438.74.camel@thedude \
    --to=mephx.x@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox