Hi,

There is a tool exactly like eselect that already exists... Its called
alternatives and its comes with dpkg.. It might be a good idea to just
use it... instead of re-inventing the wheel..

Olivier

On Thu, 2004-04-11 at 18:21 +0000, Ciaran McCreesh wrote:
> On Thu, 4 Nov 2004 18:02:41 +0100 Thomas de Grenier de Latour
> <degrenier@...> wrote:
> | 1) Write an eclass that deals with that issue in a generic way.
> | Lets call it alternatives-symlink.eclass. What are the different
> | alternatives is declared by the ebuild using an env var, for
> | instance:
> |   ALTERNATIVES="/usr/bin/vi:vim /usr/bin/view:vim /usr/bin/ex:vim"
> | (you can also use absolute path in second hand of each
> | declaration if needed.)
> 
> Ok, yup, at first glance I'm liking this. Dunno if it'll survive
> scrutiny, but... If it turns out that it's worth creating a generic
> solution to this, what should it do? Here's some rough ideas of what it
> would need to handle...
> 
> * Multiple versions of the same package, the way the current
> alternatives eclass handles things. For example, I might have foo-2.2
> and foo-2.3 installed, and I'd need a link (not user switchable) from
> foo to foo-2.3. This link must be handled even when packages are
> unmerged, upgraded and so on.
> 
> * Multiple versions of the same package with a sysadmin switchable
> symlink between versions. Basically a generic equivalent of gcc-config.
> 
> * Multiple packages wanting the same convenience symlink. For example,
> vim, nvi, elvis and vi all want to provide 'vi', 'ex' and so on. This
> should be sysadmin-switchable, but if the currently selected provider is
> unmerged then a new default should be picked. At no point should we end
> up with duff symlinks.
> 
> Regarding the last point -- personally I reckon it would be better if we
> could switch multiple packages at once through this. Like, for example,
> a 'vi' target would set the symlinks for vi, view and ex, and a gcc
> target would set the whole toolchain thing.
> 
> Something like:
> 
> # eselect --set vi vim
> # eselect --set kernel linux-2.6.7
> # eselect --set gcc sparc-unknown-linux-gnu-3.3.4
> 
> and:
> 
> # eselect --list kernel
> linux-2.6.7      (*)
> linux-2.6.8.1
> linux-2.6.10_rc1
> 
> and:
> 
> # eselect --list
> gcc              sparc-unknown-linux-gnu-3.3.4
> kernel:          linux-2.6.7
> vi:              /usr/bin/vim
> 
> could be rather cool. So... I guess the question really is, is it worth
> making all this generic and flexible, or is it simpler to just keep the
> current collection of blah-config tools and make more as needed? Can we
> nick any ideas from the Debian system? Will this idea still look good
> when I haven't had large numbers of girly foofoo drinks?

-- 
Olivier Crête
tester@g.o
Gentoo Developer