Re: [gentoo-dev] eselect modules

[Jeremy Huddleston]

> 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