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 <[EMAIL PROTECTED]>
[ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ]
--
[email protected] mailing list
