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: Mon, 11 May 2009 20:09:18 +0100 [thread overview]
Message-ID: <1242068958.4051.19.camel@thedude> (raw)
In-Reply-To: <20090510225651.GB17162@aerie.halcy0n.com>
On Sun, 2009-05-10 at 18:56 -0400, Mark Loeser wrote:
> Sérgio Almeida <mephx.x@gmail.com> said:
> > Abstract:
> >
> > Universal Select Tool is an utility to manage system configuration.
> > This tool is similar to the unmaintained eselect utility of Gentoo or
> > Exherbo's eclectic. The idea is to create a tool that manages both
> > system settings and user settings with profile creation possibilities.
> > The utility will use mostly concepts from "modules", "softenv", and
> > both "eselect" and "eclectic".
>
> I guess this is a very high level question...but do we need yet another
> eselect? Why can't we enhance or fix what we already have rather than
> creating everything from scratch?
>
Mark,
>From my point of view, uselect is not YA eselect. eselect wasn't thought
from the beginning to be universal and therefore it would need a full
re-write as you suggest. At this point (and SoC hasn't yet started) I
have implemented uselect with all eselect capabilities in python (served
as well to un-rust myself from python programming) and it is extremely
faster. uselect supports modules in any scripting language (implemented
too) and eselect only supports bash. uselect new architecture supports
the auto-creation of simple symlinking/environment/alias modules (most
of them will be it) using only a few regular expressions to define what
to change and not how to change (uselect will do it for you).
At this point eselect may be considered deprecated as it's
functionalities are limited and there is no much we can do besides
bloating bash code (what you call enhance) and bugfixing.
Let us all consider uselect another utility with some "similar"
functionalities from eselect but with a lot more features from modules
and softenv.
I knew your question would pop up and it is important to everyone to
know the differences between the two utilities.
I will post (in a near future) an example package for everyone to test
and give it's opinion on how should every idea work instead of leaving
all the decisions to me.
Thanks.
Cheers,
Sérgio
--
Sérgio Almeida <mephx.x@gmail.com>
mephx @ freenode
next prev parent reply other threads:[~2009-05-11 19:44 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 [this message]
2009-05-12 8:40 ` Michael Haubenwallner
2009-05-12 14:32 ` Sérgio Almeida
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=1242068958.4051.19.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