Subject: Re: Symlinking ruby${RUBY_VER} to ruby?
To: Takahiro Kambe <>
From: Julio M. Merino Vidal <>
List: tech-pkg
Date: 10/03/2005 15:27:01
On 10/3/05, Takahiro Kambe <> wrote:
> In message <>
>         on Sun, 2 Oct 2005 17:51:00 +0200,
>         "Julio M. Merino Vidal" <> wrote:
> > > Do you mean lang/ruby package?  Yes it depends on specific to
> > > ruby${RUBY_VER}; it creates binary package ruby-${RUBY_VER}nb2.tgz an=
> > > user can select to install either of ruby-1.8.2nb2.tgz or
> > > ruby-1.6.8nb2 package.
> >
> > Aha.  But how do you get that to work with a bulk build?  Won't it buil=
d just
> > a single pakcage?
> Yes and I understand alternatives's merit well know (I'll prepare to
> support it.)
> But is it the best way to recognize existence of ruby executable on
> other package's configure stage?  It cause depends on pkg_alternatives
> package unless pkg_alternatives resides in base system (or pkg_install).

I don't think so.  pkg_alternatives are provided to simplify the task of th=
administrator, but pkgsrc must not rely on them for anything.  Doing so
could be dangerous for several reasons:

- The administrator may have disabled alternatives for ruby.  See the 'filt=
  configuration file in /usr/pkg/etc/pkg_alternatives.
- The ruby wrapper may be pointing to a version that does not match what
  'make configure' wants.

The only solution I can see is to configure packages against a specific
version of ruby, as we do with python now.  (I guess ruby does this too,
right?)  Also, if what you need is a generic 'ruby' name during configure,
you can symlink it inside the buildlink directory :-)


Julio M. Merino Vidal <>
The NetBSD Project -