Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Feb 2015 17:18:25 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 197791] change in how dependencies are specified at build time and registered at install time
Message-ID:  <bug-197791-13@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 197791
           Summary: change in how dependencies are specified at build time
                    and registered at install time
           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: vivek@khera.org
                CC: portmgr@FreeBSD.org

I have some local ports I use to quickly configure new servers. They are
basically lists of dependencies that pull in what the specific server function
requires, such as mail server or web server.

Recently, my local package builder (using poudriere) started rebuilding a
couple of ports every run claiming "new dependency" was found.

I traced it down to the following RUN_DEPENDS:

        emacs>=23.3:${PORTSDIR}/editors/emacs-nox11 \

This was confusing the dependency registration of the port; that is, "make
depends" would notice it needed emacs, then install it. However, when "make
install" would run, the resulting package did not register the dependency for
emacs. The fix was to remove the ">=23.3" version check. My suspicion is that
it has something to do with emacs-nox11 being a slave port.

Similarly, this RUN_DEPENDS caused markdown-mode.el to be unregistered the same
way (it installed the dependency, but did not register it):

        textproc/markdown-mode.el:${PORTSDIR}/textproc/markdown-mode.el \

The fix for this situation is to add ">0" as a version dependency. I do not
know why this started to fail recently.


Also, the following LIB_DEPENDS results in the same situation: the dependency
gets installed but not registered:

 LIB_DEPENDS=    tcnative-1:${PORTSDIR}/www/tomcat-native

Looking at other ports, it seems that I now need to change the library to

 LIB_DEPENDS=    libtcnative-1.so:${PORTSDIR}/www/tomcat-native

which resolves the registration of the dependency. Again, I do not know when
this format was changed, but it is relatively recently. It did work when I
first used this in October 2013 and I'm fairly certain it was working at least
in November 2014.

-- 
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-197791-13>