The idea is to prevent needing to patch source files for packages that
use OpenSSL for DES support by ensuring that including <openssl/des.h>
will always present the old DES API.
(1) If des_old.h exists, then we're using OpenSSL>=0.9.7, and
<openssl/des.h> already does the right thing.
(2) If des_old.h doesn't exist, then one of two things is happening:
(a) If <openssl/des.h> is old and (only) supports the old DES API,
then <openssl/des.h> does the right thing.
(b) If it's NetBSD's Special(TM) one that stripped out the old DES
support into a separate library and header (-ldes, <des.h>),
then we create a new header <openssl/des.h> that includes the
system one and <des.h>.
Also modify existing packages that set USE_OLD_DES_API to simply include
<openssl/des.h> instead of either <des.h> or <openssl/des_old.h> (This
step is mostly just removing unnecessary patches).
This should fix building packages that use OpenSSL's old DES API support
on non-NetBSD systems where the built-in OpenSSL is at least 0.9.7.
pkgsrc and in NetBSD-1.6.x) and OpenSSL 0.9.7 (in NetBSD-2.0), by
creating a new yes/no variable USE_OLD_DES_API that flags whether the
package wants to use the old DES API. If USE_OLD_DES_API is "yes",
then:
* For OpenSSL 0.9.6, symlink ${BUILDLINK_DIR}/include/openssl/des_old.h
to ${SSLBASE}/include/openssl/des.h.
* For NetBSD 2.0's "special" installation of OpenSSL 0.9.7, symlink
${BUILDLINK_DIR}/include/openssl/des_old.h to /usr/include/des.h,
and transform "-lcrypto" into "-ldes -lcrypto". This makes it
behave like stock OpenSSL 0.9.7 where the old DES functions are
part of libcrypto.
Software that wants to use the old DES API should be taught to do it
in a way that works with a stock installation of OpenSSL 0.9.7 -- by
including <openssl/des_old.h> and linking against "-lcrypto". Software
that wants to use the new DES API should simply depend on openssl>=0.9.7.
This change has no impact on existing packages as the new code is
active only when USE_OLD_DES_API == "yes".
Changes between 0.9.6l and 0.9.6m [17 Mar 2004]
*) Fix null-pointer assignment in do_change_cipher_spec() revealed
by using the Codenomicon TLS Test Tool (CAN-2004-0079)
[Joe Orton, Steve Henson]
built-in or not into a separate builtin.mk file. The code to deal
checking for built-in software is much simpler to deal with in pkgsrc.
The buildlink3.mk file for a package will be of the usual format
regardless of the package, which makes it simpler for packagers to
update a package.
The builtin.mk file for a package must define a single yes/no variable
USE_BUILTIN.<pkg> that is used by bsd.buildlink3.mk to decide whether
to use the built-in software or to use the pkgsrc software.
