ports/148101: x11/startup-notification Makefile missing library dependencies [patch]

[Don Lewis]

On 24 Jun, mezz at FreeBSD.org wrote:
> Synopsis: x11/startup-notification Makefile missing library dependencies [patch]
> 
> State-Changed-From-To: open->closed
> State-Changed-By: mezz
> State-Changed-When: Thu Jun 24 20:11:13 UTC 2010
> State-Changed-Why: 
> If portupgrade inable to understand what need to do then it's a portupgrade
> bug. The portmaster will do it in order correct by check lower dependencies
> first before update main port. This port already has all dependencies listed
> by view in 'make all-depends-list' and no pointyhat failure.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=148101

Without the patch, these are the dependencies for startup-notification:

scratch:~ 74>pkg_info -r startup-notification-0.10
Information for startup-notification-0.10:

Depends on:
Dependency: kbproto-1.0.4
Dependency: pkg-config-0.23_1
Dependency: xproto-7.0.16
Dependency: libXdmcp-1.0.3
Dependency: libXau-1.0.5
Dependency: libpthread-stubs-0.3_3
Dependency: libxcb-1.6
Dependency: xcb-util-0.3.6_1
Dependency: libX11-1.3.3,1

startup-notification wants to link against libSM:

/bin/sh /usr/local/bin/libtool --tag=CC   --mode=link cc  -O2 -pipe -fno-strict-
aliasing -Wall -no-undefined -L/usr/local/lib -o libstartup-notification-1.la -r
path /usr/local/lib sn-common.lo sn-internals.lo sn-launchee.lo sn-launcher.lo s
n-list.lo sn-monitor.lo sn-util.lo sn-xmessages.lo sn-xutils.lo -L/usr/local/lib
 -lxcb   -L/usr/local/lib -lxcb-aux -lxcb   -L/usr/local/lib -lxcb-event -lxcb
 -L/usr/local/lib -lxcb-atom -lxcb    -L/usr/local/lib -R/usr/local/lib  -lSM -l
ICE -lX11

but none of the dependencies listed above will cause x11/libSM to be
installed.

x11/libSM also doesn't show up in the output of "make all-depends-list":

scratch# make all-depends-list
/usr/ports/devel/gmake
/usr/ports/x11/libX11
/usr/ports/devel/libtool22
/usr/ports/devel/pkg-config
/usr/ports/x11/xcb-util
/usr/ports/devel/gettext
/usr/ports/x11/libxcb
/usr/ports/devel/xorg-macros
/usr/ports/x11/bigreqsproto
/usr/ports/x11/xcmiscproto
/usr/ports/x11/xextproto
/usr/ports/x11/xtrans
/usr/ports/x11/kbproto
/usr/ports/x11/inputproto
/usr/ports/x11-fonts/xf86bigfontproto
/usr/ports/x11/libXau
/usr/ports/x11/libXdmcp
/usr/ports/x11/xproto
/usr/ports/devel/automake110
/usr/ports/devel/autoconf262
/usr/ports/devel/gperf
/usr/ports/converters/libiconv
/usr/ports/devel/libcheck
/usr/ports/textproc/libxslt
/usr/ports/x11/xcb-proto
/usr/ports/devel/libpthread-stubs
/usr/ports/lang/python26
/usr/ports/lang/perl5.10
/usr/ports/devel/automake-wrapper
/usr/ports/devel/m4
/usr/ports/misc/help2man
/usr/ports/devel/autoconf-wrapper
/usr/ports/security/libgcrypt
/usr/ports/textproc/libxml2
/usr/ports/devel/p5-Locale-gettext
/usr/ports/security/libgpg-error


Also, I thought it was the policy that when a port directly links
against a library that it should be explicitly be specified as a
dependency rather than to rely on other dependencies to implicitly bring
it in.  For instance, if a library has a version bump, then everything
that links against this library should be rebuilt, but if the library is
not explicitly specified as a dependency then the previously compiled
version of the port might still reference the old version at the same
time as one of its other libraries which was recompiled would
referencethe new version.  I could be mis-remembering this, though.