"Jeremy C. Reed" <reed@reedmedia.net> writes:

> On Thu, 29 Jan 2004, Hal Snyder wrote:
>
>> As noted in a previous posting, the latest release of Erlang, R9C-0
>> for which there is a netbsd package (thanks). But for crypto, this
>> release wants openssl-0.9.7a, per
>>   http://www.erlang.org/doc/r9c/doc/highlights.html -
>
> This doesn't mention if it uses some API that is not compatible with
> older version. Does old version work?

I believe the package builds on i386 solaris but does not find a
compatible openssl in configure stage when the older openssl is
installed. You get a usable Erlang run-time, minus crypto.

> I don't know erlang, but I see our package already uses openssl. Is
> it broken?

I suspect w.r.t openssl that it is.

>> and netbsd pgksrc offers openssl-0.9.6l as of the 2004-1-5 Makefile.
>
> By the way, I think jschauma said he had a 0.9.7x already packaged
> and available but he did the update in pkgsrc for 0.9.6 instead.

Well, NetBSD has openssl 0.9.7c in /usr/bin - but this is not found on
Solaris.

> I recall reading a message from about this, but can't find it.
>
>> What is the recommended pkgsrc Makefile approach to get a
>> coexisting alternate version, say in /usr/pkg/openssl-0.9.c/.. ?

> There is not a pkgsrc way now. They would have conflicting files.

pkgviews? (just getting up to speed on buildlink - pkgviews is next)

NetBSD supports coexisting versions with gcc, doesn't it?

We run servers 24x7 and occasionally need to deploy programs depending
on a newer version of a lib (openssl, freetds, etc.) without breaking
services already running.

>> Or is there a better way?
>
> Try old version. And if doesn't work, either patch erlang or send-pr so
> openssl gets updated.

Working on it.

We're continuing with pkgsrc and Erlang, but for the time being have
hammered together an i386 solaris pkgsrc binary package linking an
out-of-tree openssl (in /usr/local/openssl-0.9.7b). This is a
temporary work-around; I'm still very much interested in a better fix
as understanding of pkgsrc improves.

BTW, the Erlang package should have its own buildlink[2?|3?] file.

1. Some other programs, such as yaws, need C headers it exports.

2. Erlang programs will need to find Erlang headers (*.hrl) and
   application files (*.app) in order to build .boot and .script files
   within a pkgsrc setting.

Will send one in when we get there, if no one else beats me to it.

Thanks!