Flameeyes mentions some possible eselect project for SoC. I’d like to add a project idea to that: rework eselect so that it has an interface at a higher level. Please explain to me why I have to write 195 lines of code (rails.eselect) just to manage a symlink to a binary. It seems to me that this is what most eselect modules are doing, so this case should be really easy, and just a matter of configuration. I’m sure some of the eselect modules are doing more complicated things, but that can be solved by providing hooks.
I’d rather specifiy something like this (and not make silly mistakes in the bash code like in the current eselect modules):
TITLE="Ruby on Rails" DESCRIPTION="Some more verbose, multiline, stuff" TARGET="/usr/bin/rails" PROVIDERS="/usr/bin/rails-2.0* /usr/bin/rails-1.2* /usr/bin/rails-1.1*"
This is a bit of a simplistic example. I’m sure a slightly more complicated format would be needed to handle some of the common cases, including additional binaries, man pages, etc. Determining that would require taking inventory on the current eselect modules and seeing the common patterns, which makes it, uhm, a project.
Powered by Publify | Photo Startup stock photos