Bug 187076 - PREFIX!=/usr/local prevents package build for security/openssl,sysutils/monit
PREFIX!=/usr/local prevents package build for security/openssl,sysutils/monit
Status: Closed FIXED
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s)
Latest
Any Any
: Normal Affects Only Me
Assigned To: FreeBSD ports mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-25 23:30 UTC by dewayne
Modified: 2014-03-03 11:20 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dewayne 2014-02-25 23:30:00 UTC
Setting the PREFIX to something other than /usr/local prevents both packages (openssl, monit) being built due to "missing" man pages.

Workarounds
1. Reverting openssl resulted in a built openssl package.  
2. Changing PREFIX from /usr to /usr/local resulted in both openssl and monit package success.
Suggesting that, during the package assembly, the documentation is expected under /usr/local.

---
For openssl, after cd /usr/ports/security/openssl && make -DBATCH package,
the compilation completes but the package is not built due to 

Creating bzip'd tar ball in
'/var/ports/usr/ports/security/openssl/work/openssl-1.0.1_9.tbz'
tar: man/man1/CA.pl.1.gz: Cannot stat: No such file or directory
tar: man/man1/asn1parse.1.gz: Cannot stat: No such file or directory
..
tar: man/man7/des_modes.7.gz: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
pkg_create: make_dist: tar command failed with code 256
*** [do-package] Error code 1

Similarly, after reverting /usr/ports/security/openssl with 
svn checkout -r 340722 svn://freebsd.riverwillow.net.au/ports/head/security/openssl /usr/ports/security/openssl

For my build-set, the next failure occurs with monit
===>  Building package for monit-5.7
tar: man/man1/monit.1.gz: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
pkg_create: make_dist: tar command failed with code 256
Creating package /var/ports/usr/ports/sysutils/monit/work/monit-5.7.tbz
Registering depends:.
Creating bzip'd tar ball in
'/var/ports/usr/ports/sysutils/monit/work/monit-5.7.tbz'
*** [do-package] Error code 1

---------
Other port related variables:
From ports.conf
sysutils/monit: PREFIX=/usr | monit_SET=SSL
security/openssl: PREFIX=/usr  | UNSET=I386 RC5 | openssl_SET=SSE2 ASM MD2 OPENSSL_COMPRESSION PADLOCK EC

From make.conf 
WRKDIRPREFIX=/var/ports
DISTDIR=/distfiles
TMPDIR=/tmp
PACKAGES=/packages

STAGEDIR=/usr/staging
FAVORITE_COMPILER=gcc
DEFAULT_VERSIONS=perl5=5.16 python=2.7 python2=2.7 apache=22
DISABLE_VULNERABILITIES=yes   # All packages are built fresh from latest svn
NO_WARNING_PKG_INSTALL_EOL=yes
WITH_CCACHE_BUILD=yes

WITHOUT_DEBUG=true
WITHOUT_PROFILE=true
DOC_LANG="en_US.ISO8859-1"

How-To-Repeat: In ports.conf 
sysutils/monit: PREFIX=/usr
security/openssl: PREFIX=/usr
or 
make.conf
PREFIX=/usr

cd /usr/ports/sysutils/monit && make -DBATCH clean deinstall package
cd /usr/ports/security/openssl && make -DBATCH clean deinstall package
Comment 1 dewayne.geraghty 2014-02-27 22:33:28 UTC
When using PREFIX=/usr, a workaround to the: tar stat failure to acquire
man pages into the package, is to add MANPREFIX=/usr.  Not a desirable
outcome but if the recency of the package is more important than having
man pages, this "works".
Comment 2 Mark Linimon freebsd_committer 2014-03-02 03:20:21 UTC
State Changed
From-To: open->feedback

set to feedback after fixing Synopsis and adding maintainers to 
X-GNATS-Notify.
Comment 3 Dirk Meyer freebsd_committer 2014-03-02 13:09:58 UTC
State Changed
From-To: feedback->closed


builds fine with non default PREFIX 

/usr/ports/current/openssl$ make package PREFIX=/usr/test 


The builds fails only when PREFIX=/usr: 

bsd.port.mk sets MANPREFIX 
.if ${PREFIX} == /usr 
MANPREFIX?=     /usr/share 
.else 
MANPREFIX?=     ${PREFIX} 
.endif 

With staging the manpages can not be found. 
If the port would use PREFIX instead of MANPREFIX 
the package wild build but the manpages wound not work. 

Before staging, the MAN* macros did handle that well. 

But PREFIX=/usr is not supported since FreeBSD 5.0 
openssl in /usr will needs lots of changes to work. 

Normal PREFIX: 

/usr/lib/libssl.a 
/usr/lib/libssl.so 
/usr/lib/libssl.so.6 
/usr/local/lib/libssl.a 
/usr/local/lib/libssl.so 
/usr/local/lib/libssl.so.8 
/lib/libcrypto.so.6 
/usr/lib/libcrypto.so 
/usr/local/lib/libcrypto.so 
/usr/local/lib/libcrypto.so.8 

If you install with PREFIX=/usr, 
you will have incompatible versions of the openssl libs your system. 
as "/lib/libcrypto.so.6" is not updated. 
This will cause applications to fail.
Comment 4 dfilter freebsd_committer 2014-03-02 13:13:35 UTC
Author: dinoex
Date: Sun Mar  2 13:13:27 2014
New Revision: 346762
URL: http://svnweb.freebsd.org/changeset/ports/346762
QAT: https://qat.redports.org/buildarchive/r346762/

Log:
  - error out early if users trying to break their base system
  PR:		187076

Modified:
  head/security/openssl/Makefile

Modified: head/security/openssl/Makefile
==============================================================================
--- head/security/openssl/Makefile	Sun Mar  2 13:00:26 2014	(r346761)
+++ head/security/openssl/Makefile	Sun Mar  2 13:13:27 2014	(r346762)
@@ -78,6 +78,10 @@ FIX_POD=apps/cms.pod \
 
 .include <bsd.port.pre.mk>
 
+.if ${PREFIX} == /usr
+IGNORE=	OpenSSL can not be installed over the base version
+.endif
+
 OPENSSL_BASE_SONAME!=	readlink ${DESTDIR}/usr/lib/libcrypto.so || true
 OPENSSL_SHLIBVER_BASE=	${OPENSSL_BASE_SONAME:E}
 OPENSSL_BASE_SOPATH=	${OPENSSL_BASE_SONAME:H}
_______________________________________________
svn-ports-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-ports-all
To unsubscribe, send any mail to "svn-ports-all-unsubscribe@freebsd.org"
Comment 5 dewayne.geraghty 2014-03-03 11:06:26 UTC
On 3/03/2014 5:21 PM, Dirk Meyer wrote:
> Hallo Dewayne Geraghty,
>
>> Though I have been building openssl from ports into the base system for
>> since 2006.  And that is where it resides today, in all the servers that
>> we have deployed to customers, along with select packages like heimdal
>> and openssh (into /usr).
> OpenSSL in base has only been working in FreeBSD 4.x
>
>> [...] than I do ensuring that we have latest executables, libs.
> Sadly this ist not the case.
>
> the base apps will still use the old base libs.
>
> $ ldd /usr/sbin/sshd | grep libcrypto
>  libcrypto.so.6 => /lib/libcrypto.so.6 (0x33e5a000)
>
> $ ldd /usr/sbin/wpa_supplicant
>  libssl.so.6 => /usr/lib/libssl.so.6 (0x33d05000)
>  libcrypto.so.6 => /lib/libcrypto.so.6 (0x33d51000)
>
>> I had considered building packages for a non /usr location but that
>> wasn't really the right thing to do, so its a balancing act.  The
>> argument regarding libcrypt.so.6 and others is reasonable.
> You are in luck that the config location is different.
> /usr/ssl/openssl.conf
> /usr/openssl/openssl.conf
>
> else your apps might not work at all.
>
> kind regards Dirk
>
> - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany
>
>

Thank-you Dirk, You're quite right.  Though I avoid those problems by
using a skeleton FreeBSD, where I don't build ssh, heimdal, hostapd,
named, ntp during a system build but rely upon packages from ports. 

Some time ago, I used to not build openssl, however subsequent geom_eli
versions pulled in some headers from the base openssl, requiring a
simple work-around.  More recently pkg_* and fetch need libssl or
libcrypto ...  but it is gssd that really upset the apple-cart (made
things difficult).

Yes many of the base applications use libcrypt.so.6 and less than 10 use
libssl.so.6.  Of the 487 ports that I use, the only port that require
these libraries is pkg.  The other ports build cleanly with
libcrypto.so.8 &/or libssl.so.8.  I'm probably fortunate that none link
to both lib{ssl,crypto}.so.6 and .8, but for those that do, maybe they
should be corrected?

Thank-you for your thoughts, you've reminded me what a nuisance this was
when I first took this path (of replacing base contributions with
packaged elements).   But there is some consolation that I regard an
operating system only as useful as the applications that it reliably
runs - the base elements of FreeBSD: Kernel, IO, network infrastructure,
device and memory management provide an outstanding base platform but
its the ports system that provides utility to businesses, and, with
timely revisions provides for more than just a fun experience; a genuine
business advantage. :) 

Unfortunately there is no luck involved, careful analysis and planning
is required.  And your choice of wpa_supplicant is a poignant example,
as it is at revision 0.7.3 (on FreeBSD 9.2Stable) while the latest
software is at revision 2.1
(http://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog).  I would
probably use a port if it was available, because TLS1.2 is attractive,
though if the FreeBSD developers have left this software alone, its
precautionary to examine why more closely. ;)

Kind regards, Dewayne
Australia.