Re: [gentoo-dev] eselect modules

[Danny van Dyk <kugelfang@gentoo.org>]

-----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