[ NOTE: moved to tech-pkg ]

[ On Tuesday, July 4, 2000 at 13:40:28 (+0200), Hubert Feyrer wrote: ]
> Subject: Re: suggestion for pkg_tools
>
> There are two things you ask for here:
> a) use a non-pkgsrc perl
> b) don't put a hard depend on perl
> 
> We've decided against a) a long time ago, as we can't know which perl you
> have installed, how it is configured, etc. This caused an endless stream
> of problems, plus it's a non standard case - you're expected to either use
> a system tha comes only from pkgsrc, or not at all - mixing is not good.

Just to clarify I really do hope that nobody's changing BUILD_DEPENDS to
DEPENDS in the case of reasonably generic tools such as 'perl'.  This
would make life somewhat more difficult for people who do a lot of
maintenance work but who don't use pkgsrc for everything.  If I have my
own version of perl installed manually and a package needs perl *only*
to build then I wouldn't be very happy if pkgsrc decided to install its
own version too.  Mixing manually installed packages and pkgsrc packages
on the same system is a fact of life for those of us who do a lot of
third-party maintenance.

> For b) this needs some subtle changes to packages, which is not easy to
> work out: some GNU autoconf scripts detect perl automatically, so there
> may no be much work to do there. Other packages may need additional
> patches, configure arguments, different PLIST etc. to disable/enable perl
> support - right now, we don't have an infrastructure to accomodate that.

Also to clarify:  There is enough infrastructure to accomodate at
minimum the disable/enable option, though indeed it still might be more
work for pkgsrc maintainers than it is worth.

In the case of package run-time dependencies it is indeed very important
for pkgsrc perl to be used, and for a package dependency to be declared,
though not necessarily for all of the reasons you say.  The most
critical reason is to ensure that binary packages will work.  In most
cases the exact point version of perl is not really important.
Unfortunately though in the particular case of perl (and some other
script interpreters) it is important to know at build time the location
of the installed interpreter to be used a run time and with pkgsrc this
absolutely requires the package dependency to be declared.

It might be interesting to add something like a properly working
RUN_DEPENDS declaration (*) that can specify a program that's needed
only at run time so that the pkg_add could check for it and only install
the pkgsrc version if no version is found on the system.  In this case
if any "perl" is found then it would be assumed to be used.  The only
yucky part about this is, as I say, that most interpreted scripts depend
on the install location of the interpreter.  However if you're willing
to hack the necessary symlinks into place to accomodate random 3rd-party
scripts then this trick would work quite well.

(*) I note that RUN_DEPENDS did work as I describe it to in FreeBSD's
system for a pkgsrc install, but not for pkg_add as there doesn't seem
to be an equivalent type of test for it; all there is are @pkgdep
entries which explictly require the listed package to be installed.
Note that by the time you get to running the REQUIRE script it's too
late to be declaring optional package dependencies....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>