> 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
signature.asc
Description: This is a digitally signed message part
