Re: [gentoo-dev] Handling multiple packages providing the same convenience symlink

[Ciaran McCreesh]

On Thu, 4 Nov 2004 18:02:41 +0100 Thomas de Grenier de Latour
<degrenier@×××××××××××.fr> 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?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm