On 10/3/05, Takahiro Kambe <taca@back-street.net> wrote:
> In message <6b2d1e190510020851x5d5eb91ep3a32d288985ce9f3@mail.gmail.com>
>         on Sun, 2 Oct 2005 17:51:00 +0200,
>         "Julio M. Merino Vidal" <jmmv84@gmail.com> 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=
d
> > > 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=
e
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=
er'
  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 :-)

HTH,

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