Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Feb 2015 22:18:22 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 198045] Build tools hiding dependency issues
Message-ID:  <bug-198045-13@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198045

            Bug ID: 198045
           Summary: Build tools hiding dependency issues
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Ports Framework
          Assignee: freebsd-ports-bugs@FreeBSD.org
          Reporter: melvyn@magemana.nl
                CC: portmgr@FreeBSD.org

The ports system can be used using `make -C ${PORTSDIR}/category/leafport
install`. This is the simplest way to use the ports system and it will compile
all dependencies that aren't installed yet.

With build tools ranging from portmaster to poudriere building their own
dependency tree and separating the build in it's own make process, a couple of
bugs are not uncovered by maintainers, because the top-level makefile is no
longer the leaf port being installed:

1. Exists checks:

.if !exists(/path/to/file/to/be/installed/by/dep)
BROKEN= Port needs foo with option bar
.endif

Case in point: x11-toolkits/pango.
Fails when: dependency is not installed
Fails because: exists check is done in top-level Makefile result not
re-evaluated after dependency is installed.
Fix: use if [ ! -f ] in sh, rather then make's version.

2. Ports with different version of interpreter in upwards dependencies

DEFAULT_VERSIONS=    python=3.3
Upwards dependency forces python=2.7.

Case in point: graphics/qt4-opengl => graphics/libGL => py27-libxml:build =>
setuptools
Fail symptom: pkg complains about /usr/local/bin/easy_install
Fails because: not entirely sure, but I suspect that the DEFAULT_PYTHON_VERSION
is being mangled downstream, causing the unversioned easy_install to be
installed again.

3. Versions obtained from parsing output of != statements

BUILD_DEPENDS+= foo:${PORTSDIR}/misc/foo
FOO_VERSION!= ${LOCALBASE}/bin/foo -V
PLIST_SUB+= FOO_VERSION=${FOO_VERSON}
pkg-plist: lib/bar-foo-%%FOO_VERSION%%.so.1

Case in point: used to be in bsd.xorg.mk for Xorg Server. Don't know if this is
still in a different incarnation used elsewhere
Fail symptom: package install fails with files not being present
Fail reason: FOO_VERSION is empty at evaluation time and not reevaluated when
dependency is installed. Upstream build/install system does however pick up the
right version at build time of leaf port resulting in packing list looking for
lib/bar-foo-.so.1 and lib/bar-foo-1.0.so.1 being in STAGEDIR.

All these are hidden by recommended test tools used by maintainers because of
above mentioned reasons, yet it should be the installation mechanism that
should always work.

So this bugreport is two-fold:
1. Is `make -C ${PORTSDIR}/category/leafport install` still considered to be
fully suported and always working?

2a. If 1) is yes, can the above be fixed and can a test tool be used that does
not separate build stages?
2b. If 1) is no,  is The Project pushing binary upgrades or ports-mgmt tools to
end users and as such should docs be updated:
http://www.freebsd.org/doc/en/books/handbook/ports-using.html

-- 
You are receiving this mail because:
You are the assignee for the bug.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-198045-13>