-----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 <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDAkP4aVNL8NrtU6IRAhEkAJ9zqqfiaruWxy+PQ1e57ybNOcgWIgCff6Y8 q0TidAU1r1rlCb6uuAwRiMM= =BY+s -----END PGP SIGNATURE----- -- [email protected] mailing list
