Moving innovations

Making people happy with innovative software

Speaking of eselect...

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.

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.

Published on 02/02/2008 at 20h53 by Hans de Graaff Tags

  • by Donnie Berkholz 05/02/2008 at 09h37

    This is what I wrote skel.bash for. It currently is written to do stuff in lib* only, but it could probably be modified fairly easily to do what you want.
  • by Ciaran McCreesh 03/02/2008 at 18h19

    This would be why we have eselect libraries, as well as modules. Quite why no-one ever used them is beyond me...
  • by Diego "Flameeyes" Pettenò 02/02/2008 at 22h42

    This is what I meant with the fourth entry in my list: an easy way to choose between alternatives _without_ having to write a new eselect module for each. I also hope it would be also _without_ having to list all the alternatives inside the module, letting the implementations themselves install a datafile saying "I'm here, you can choose me".
  • by Xake 02/02/2008 at 22h37

    What you are talking about seems to be templates? I can't recall when he was talking about it, but Uberlord have afaik implemented something like that in OpenRC. He had en example that looked something like your example of what you where looking for, but OpenRC usually still uses the "common" #/bin/sh format. But at template system could be nice, something like portages eclasses you can choose between and after that you only have some variables to set (like the one you demoed) and from that on only have to change the "defaults" for that template. Or do not use a template and have everything implanted from scratch if you want/need, thus allowing modules of the "current" sort.

comment Speaking of eselect...

Trackbacks are disabled

Powered by Publify – Thème Frédéric de Villamil | Photo Glenn