On 10/2/05, Takahiro Kambe <taca@back-street.net> wrote:
> I would not opposite to supporting alternatives framework. but I have
> a few questions.
>
> What is current status of alternatives framework?

It works fine with a little exception for interpreters (cannot use a shell
script in #! constructions).  There is a PR for this issue and should be
fixed, but for all other usages it works.

> I couldn't find documentation in pkgsrc/doc/pkgsrc.txt and

Humm... yes... I had to write that but never got to it; sorry.  ATM, you ca=
n
use existing packages as examples, such as python*, nvi or vim.  Just
check their ALTERNATIVES file.

> pkg_alternatives is optional tool.

Yes, it is, based on the request of many users.  However, the framework
is not optional.  What I mean is that you can first install the ruby packag=
es
and then, at a later step, add pkg_alternatives; the new 'ruby' name will
pop up automagically.

> So, I understand it as "another way." and there should be other way
> (as symlink ${PREFIX}/bin/ruby18 as ${WRKDIR}/.buildlink/bin/ruby or
> somthing?)

It is certainly another way, but it was added to homogenize all this stuff
in pkgsrc, specially targetting users of binary packages.  pkg_alternatives
provides complete customization of what these users get.  (Is the existing
'ruby' package binary friendly?  Or it relies on a specific version given a=
t
build time?)

Cheers,

--
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/