[gentoo-dev] Announcing eselect

[gentoo-dev] Announcing eselect

[Aaron Walker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

eselect (formerly known as eclectic (formerly known as eselect)) is now in the
tree as app-admin/eselect.  Along with the new name comes a new version, 0.9.4.

Changes in this release include:

    Bug Fixes:
    - fixed call to lapack config file in blas module.

    New Features:
    - added a testing version of binutils.eselect.
    - added (start|stop|restart) subactions to rc module.
    - implemented global options handling generally and a --no-colour
    option specificly.
    - all modules mark currently active options with a * in list subaction.

In addition, eselect is now hosted on Gentoo infrastructure.  This resulted in
quite a few other things being added as well: svn access, a new bugzilla
category (Gentoo hosted projects->eselect), a new alias for all eselect devs
(eselect@), and a new homepage[1].

[1] http://www.gentoo.org/proj/en/eselect/

Cheers
- --
Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCrY1TC3poscuANHARAnLzAJ0T6xobnE8XPqGzkhBTyBbTKAxSrgCghDJV
fViUZOBOT9TZHbmd5y3UBP4=
=CY22
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Announcing eselect

[Mike Frysinger]

On Monday 13 June 2005 09:42 am, Aaron Walker wrote:
> eselect (formerly known as eclectic (formerly known as eselect)) is now in
> the tree as app-admin/eselect.

why not the app-portage category ?
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Announcing eselect

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mike,

Mike Frysinger schrieb:
>>eselect (formerly known as eclectic (formerly known as eselect)) is now in
>>the tree as app-admin/eselect.
> 
> why not the app-portage category ?

eclectic was in the tree as app-admin/eclectic. Anything speaking
against app-admin? It is, after all a tool for administrative tasks.

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCrbDQaVNL8NrtU6IRAr4lAJwMafSXvCdF1NmiatKuVvwtoe7PJACgmbq6
gbv5IQwLEjwUgV8UNdDNDsE=
=GnNo
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Announcing eselect

[Mike Frysinger]

On Monday 13 June 2005 12:14 pm, Danny van Dyk wrote:
> Hi Mike,
>
> Mike Frysinger schrieb:
> >>eselect (formerly known as eclectic (formerly known as eselect)) is now
> >> in the tree as app-admin/eselect.
> >
> > why not the app-portage category ?
>
> eclectic was in the tree as app-admin/eclectic. Anything speaking
> against app-admin? It is, after all a tool for administrative tasks.

well since it really seems to just deal with Gentoo related stuff, app-portage 
seems to make sense to me, but really either is fine
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Announcing eselect

[Shyam Mani]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/13/2005 09:22 PM, Mike Frysinger wrote:

> why not the app-portage category ?

Since it has scope to work beyond Portage?


- --
Shyam Mani | <fox2mike@gentoo.org>
docs-team  | http://gdp.gentoo.org
GPG Key    | 0xFDD0E345
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCrcXlYZNYgP3Q40URAtB5AKCyVPHzXWKYJte3+/LyyMfaDq1EVgCfQht4
07Cm1bFBGxYgc5IYiF7kaPs=
=McpQ
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Announcing eselect

[Aaron Walker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
> On Monday 13 June 2005 09:42 am, Aaron Walker wrote:
> 
>>eselect (formerly known as eclectic (formerly known as eselect)) is now in
>>the tree as app-admin/eselect.
> 
> 
> why not the app-portage category ?
> -mike

My reason for choosing app-admin over app-portage is because eselect itself
really has nothing to do with portage or the portage tree.  It is more of an
administrative tool.

While indeed most of the modules are Gentoo-specific, the framework itself is
not limited to Gentoo.

Cheers
- --
The devil finds work for idle glands.

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCrkD9C3poscuANHARAu2EAJ9G42GImK+rrmYv+jlaqmDFC1AICwCg8lNH
3rjMBZpxYJz1De6F1TNkcgY=
=Aop6
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] eselect modules

[Jeremy Huddleston]

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]

I've recently updated opengl-update to use the eselect framework.  I
think the team has done a great job as it was extremely easy to port the
bash script to an eselect module.  However, when I placed it in the
portage tree, it sparked a little bit of a policy discussion between
myself and the core eselect devs on how to best include modules in the
tree, so I'd like to let other devs chime in as well.

Firstly if you don't know what eselect is, check out:
http://www.gentoo.org/proj/en/eselect/index.xml 

The eselect developers want to keep all eselect modules in their svn
repository and distributed through a single package (app-admin/eselect).
Their main reasons for this are better QA and less overhead for releases
and merging.

I have a problem with this policy because:
1) Stability of the modules should not be tied to stability of the core
package.  Basically, I'd like to determine when my modules get pushed
into stable without considering how it'll effect the eselect modules of
other developers.  Similarly, I don't want bugs in another module
holding up my module from going into stable.

2) Not all users will want all modules.  The goal of the eselect project
is to provide a framework to replace java-config, motif-config,
gcc-config, binutils-config, opengl-update, etc, but not all users will
need all modules.

3) Some modules require extra files (opengl-update installs header
files, gcc-config installs a wrapper, etc), and the app-admin/eselect
package is not the correct place to provide these files.

Also, what should the correct way to introduce these modules into
portage?
Should we keep them in the packages they're replacing
(x11-base/opengl-update)?
Should we place them in a new package in the same category as the script
they're replacing (x11-base/eselect-opengl)?
Should we place them in app-admin/eselect-<module name> or perhaps
app-eselect/<module name>?

Note that for backwards compatibility in all cases,
x11-base/opengl-update will RDEPEND on this eselect module and install a
backwards-compatible frontend to the eselect module until all packages
in portage have been updated to use the eselect module instead.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] eselect modules

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Huddleston wrote:
| The eselect developers want to keep all eselect modules in their svn
| repository and distributed through a single package (app-admin/eselect).
| Their main reasons for this are better QA and less overhead for releases
| and merging.

And unnecessarily tying releases together of things that have no reason
to be tied together.

It's fine to keep all the source in the same repository, but don't lock
releases of unrelated modules together. That's the same thing X went
through and has finally learned with the modularization effort.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDAjzGXVaO67S1rtsRAt/jAKC5iEbkyTvqTAm44EB1PVur7wqDiwCcC/HD
umiI6mrs67f+YBVxDAJz/0U=
=yK5P
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect modules

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

On Tue, 2005-08-16 at 12:21 -0700, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jeremy Huddleston wrote:
> | The eselect developers want to keep all eselect modules in their svn
> | repository and distributed through a single package (app-admin/eselect).
> | Their main reasons for this are better QA and less overhead for releases
> | and merging.
> 
> And unnecessarily tying releases together of things that have no reason
> to be tied together.
> 
> It's fine to keep all the source in the same repository, but don't lock
> releases of unrelated modules together. That's the same thing X went
> through and has finally learned with the modularization effort.

There's also the size issue.  I use opengl-update on the LiveCD builds,
and have exactly zero need for *any* other eselect module, so why should
I be required to have them all to just get the one that I need?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] eselect modules

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Tue, 16 Aug 2005 15:38:08 -0400 Chris Gianelloni
<wolf31o2@gentoo.org> wrote:
| There's also the size issue.  I use opengl-update on the LiveCD
| builds, and have exactly zero need for *any* other eselect module, so
| why should I be required to have them all to just get the one that I
| need?

Heh. You complain about the size of an eselect module, and then go and
include a stinkin' great bitmap splash screen.

Anyway, I'm in favour of separate distribution of modules once eselect
reaches a 1.0 release. Until then there's still a chance someone might
go and change the API...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] eselect modules

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jeremy,

(Just a note: the follwing expresses my opinion, i don't speak for the
other eselect devs)

Jeremy Huddleston schrieb:
| I've recently updated opengl-update to use the eselect framework.  I
| think the team has done a great job as it was extremely easy to port the
| bash script to an eselect module.  However, when I placed it in the
:-)

| portage tree, it sparked a little bit of a policy discussion between
| myself and the core eselect devs on how to best include modules in the
| tree, so I'd like to let other devs chime in as well.
[snip]
| The eselect developers want to keep all eselect modules in their svn
| repository and distributed through a single package (app-admin/eselect).
| Their main reasons for this are better QA and less overhead for releases
| and merging.
My opinion is this: Keeping eselect modules inside eselect's SVN repo
results in:
a) More eyes reading the code (read: QA)
b) The possibility to change all modules in one move in case we change
~   something like a default behaviour, or function names, etc.

Having all modules in the same repository is imho more important than
having only one package to distribute it. I can happily live with
x11-base/opengl-update installing a module inside
~  /usr/share/eselect/modules
and creating a symlink for opengl-update.

| I have a problem with this policy because:
| 1) Stability of the modules should not be tied to stability of the core
| package.  Basically, I'd like to determine when my modules get pushed
| into stable without considering how it'll effect the eselect modules of
| other developers.  Similarly, I don't want bugs in another module
| holding up my module from going into stable.
Understandable.

| 2) Not all users will want all modules.  The goal of the eselect project
| is to provide a framework to replace java-config, motif-config,
| gcc-config, binutils-config, opengl-update, etc, but not all users will
| need all modules.
I agree here as well...

| 3) Some modules require extra files (opengl-update installs header
| files, gcc-config installs a wrapper, etc), and the app-admin/eselect
| package is not the correct place to provide these files.
jupp...

| Also, what should the correct way to introduce these modules into
| portage?
| Should we keep them in the packages they're replacing
| (x11-base/opengl-update)?
| Should we place them in a new package in the same category as the script
| they're replacing (x11-base/eselect-opengl)?
| Should we place them in app-admin/eselect-<module name> or perhaps
| app-eselect/<module name>?
I'd prefer app-admin/eselect-<modulename>, but i could happily live with
app-eselect/<modulename>. But i don't think that we need a whole new
category for eselect modules. Not right now, and probably not in future,
either.

| Note that for backwards compatibility in all cases,
| x11-base/opengl-update will RDEPEND on this eselect module and install a
| backwards-compatible frontend to the eselect module until all packages
| in portage have been updated to use the eselect module instead.
Jeremy, do you know about the 'old-script-name' feature that Ciaran
introduced?
By symlinking /usr/bin/eselect to one of these

~  <module>-update, <module>-config, <module>-manager, config-<module>,
~  update-<module> or manage-<module>,

a call to it will be handles as if the user called 'eselect <module>'.
You might probably want to consider this for your opengl-update package.
app-admin/eselect currently installs these symlinks automatically:

~  kernel-config, profile-config, rc-config, bashcomp-config

Btw: Thx for you feedback on eselect. It really appreciated it :-)

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDAkP4aVNL8NrtU6IRAhEkAJ9zqqfiaruWxy+PQ1e57ybNOcgWIgCff6Y8
q0TidAU1r1rlCb6uuAwRiMM=
=BY+s
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect modules

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Tue, 16 Aug 2005 21:52:25 +0200 Danny van Dyk <kugelfang@gentoo.org>
wrote:
| b) The possibility to change all modules in one move in case we change
| ~   something like a default behaviour, or function names, etc.

That kind of thing shouldn't happen once a stable release is out...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] eselect modules

[Jeremy Huddleston]

[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]

> My opinion is this: Keeping eselect modules inside eselect's SVN repo
> results in:
> a) More eyes reading the code (read: QA)

I think the point you're trying to make here is that the QA is easier to
accomplish for you, and that certainly is true.

I think having modules in app-admin/eselect-<module>/files/ or in 

> b) The possibility to change all modules in one move in case we change
> ~   something like a default behaviour, or function names, etc.

Well, this default behavior shouldn't change once 1.0 is finished, so I
think ciaranm's point is valid.  Once 1.0 is released, the API should
stabilize, and you should let developers utilize this framework, but
until then, perhaps a little bit tighter control is prudent.

> Having all modules in the same repository is imho more important than
> having only one package to distribute it. I can happily live with
> x11-base/opengl-update installing a module inside
> ~  /usr/share/eselect/modules
> and creating a symlink for opengl-update.

Ok, then I can certainly live with this until 1.0 stabilizes (and
perhaps longer if the development model works well) as long as it's the
repository we're talking about and not the package or tarball (meaning
I'd like to bzip2 my eselect module from the repository and use that in
the package rather than getting it out of an eselect-<version> tarball).

> I'd prefer app-admin/eselect-<modulename>, but i could happily live with
> app-eselect/<modulename>. But i don't think that we need a whole new
> category for eselect modules. Not right now, and probably not in future,
> either.

Yeah, app-admin/eselect-<module name> seems reasonable.

> Jeremy, do you know about the 'old-script-name' feature that Ciaran
> introduced?
> By symlinking /usr/bin/eselect to one of these
> 
> ~  <module>-update, <module>-config, <module>-manager, config-<module>,
> ~  update-<module> or manage-<module>,
> 
> a call to it will be handles as if the user called 'eselect <module>'.
> You might probably want to consider this for your opengl-update package.

Actually, no I didn't, but I'll look into it later tonight.

Thanks,
Jeremy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] eselect modules

[Aaron Walker]

Jeremy Huddleston wrote:
> I've recently updated opengl-update to use the eselect framework.  I
> think the team has done a great job as it was extremely easy to port the
> bash script to an eselect module.  However, when I placed it in the
> portage tree, it sparked a little bit of a policy discussion between
> myself and the core eselect devs on how to best include modules in the
> tree, so I'd like to let other devs chime in as well.
> 
> Firstly if you don't know what eselect is, check out:
> http://www.gentoo.org/proj/en/eselect/index.xml 
> 
> The eselect developers want to keep all eselect modules in their svn
> repository and distributed through a single package (app-admin/eselect).
> Their main reasons for this are better QA and less overhead for releases
> and merging.

QA is my main concern.

> 
> I have a problem with this policy because:
> 1) Stability of the modules should not be tied to stability of the core
> package.  Basically, I'd like to determine when my modules get pushed
> into stable without considering how it'll effect the eselect modules of
> other developers.  Similarly, I don't want bugs in another module
> holding up my module from going into stable.

agreed.

> 
> 2) Not all users will want all modules.  The goal of the eselect project
> is to provide a framework to replace java-config, motif-config,
> gcc-config, binutils-config, opengl-update, etc, but not all users will
> need all modules.
> 
> 3) Some modules require extra files (opengl-update installs header
> files, gcc-config installs a wrapper, etc), and the app-admin/eselect
> package is not the correct place to provide these files.

agreed.

> 
> Also, what should the correct way to introduce these modules into
> portage?
> Should we keep them in the packages they're replacing
> (x11-base/opengl-update)?
> Should we place them in a new package in the same category as the script
> they're replacing (x11-base/eselect-opengl)?
> Should we place them in app-admin/eselect-<module name> or perhaps
> app-eselect/<module name>?

Good question.  I don't really have a preference.

> 
> Note that for backwards compatibility in all cases,
> x11-base/opengl-update will RDEPEND on this eselect module and install a
> backwards-compatible frontend to the eselect module until all packages
> in portage have been updated to use the eselect module instead.
> 

It's been my opinion from the beginning that not allowing modules to be 
distributed outside of eselect limits its flexibility.  However, I've kept my 
foot down to this point soley for QA reasons.  It'd be a nightmare to keep 
track of the modules if they were all over the tree in various packages' files/ 
directories.

After thinking about this a bit and reading the other responses you've gotten 
so far, I think we should keep all the modules in the main subversion 
repository and allow the modules to be distributed separately (once we have a 
stable API of course).

Yay or nay on this?

-- 
    "Summer is butter on your chin and corn mush between every tooth." -Calvin

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect modules

[Bjarke Istrup Pedersen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Huddleston skrev:
> I've recently updated opengl-update to use the eselect framework.  I
> think the team has done a great job as it was extremely easy to port the
> bash script to an eselect module.  However, when I placed it in the
> portage tree, it sparked a little bit of a policy discussion between
> myself and the core eselect devs on how to best include modules in the
> tree, so I'd like to let other devs chime in as well.
> 
> Firstly if you don't know what eselect is, check out:
> http://www.gentoo.org/proj/en/eselect/index.xml 
> 
> The eselect developers want to keep all eselect modules in their svn
> repository and distributed through a single package (app-admin/eselect).
> Their main reasons for this are better QA and less overhead for releases
> and merging.
> 
> I have a problem with this policy because:
> 1) Stability of the modules should not be tied to stability of the core
> package.  Basically, I'd like to determine when my modules get pushed
> into stable without considering how it'll effect the eselect modules of
> other developers.  Similarly, I don't want bugs in another module
> holding up my module from going into stable.
> 
> 2) Not all users will want all modules.  The goal of the eselect project
> is to provide a framework to replace java-config, motif-config,
> gcc-config, binutils-config, opengl-update, etc, but not all users will
> need all modules.
> 
> 3) Some modules require extra files (opengl-update installs header
> files, gcc-config installs a wrapper, etc), and the app-admin/eselect
> package is not the correct place to provide these files.
> 
> Also, what should the correct way to introduce these modules into
> portage?
> Should we keep them in the packages they're replacing
> (x11-base/opengl-update)?
> Should we place them in a new package in the same category as the script
> they're replacing (x11-base/eselect-opengl)?
> Should we place them in app-admin/eselect-<module name> or perhaps
> app-eselect/<module name>?
> 
> Note that for backwards compatibility in all cases,
> x11-base/opengl-update will RDEPEND on this eselect module and install a
> backwards-compatible frontend to the eselect module until all packages
> in portage have been updated to use the eselect module instead.
> 

Any plans on moving webapp-config as an eselect module? :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDGzt+O+Ewtpi9rLERAiZgAKDAzrI29bEbUoVKdji4r9vaZOFFcwCdGbfo
rXlfU7yQb6qvpuMj2BR806Y=
=d86l
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] eselect modules

[Stuart Herbert]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Sun, 2005-09-04 at 20:22 +0200, Bjarke Istrup Pedersen wrote:
> Any plans on moving webapp-config as an eselect module? :-)

No.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] eselect modules

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

On Sun, 04 Sep 2005 20:22:54 +0200 Bjarke Istrup Pedersen
<gurligebis@gentoo.org> wrote:
| Any plans on moving webapp-config as an eselect module? :-)

That one's way beyond the scope of what eselect was designed for.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]