Direct or indirect libdependencies (using the libintl.so.8 case)

[Jan Henrik Sylvester]

On 01/-10/63 20:59, Alexander Leidinger wrote:
> Quoting Peter Jeremy <peter at vk2pj.dyndns.org> (from Thu, 3 Jun 2010
> 22:37:28 +1000):
>
>> On 2010-Jun-01 10:54:02 +0200, Jan Henrik Sylvester <me at janh.de> wrote:
>>> Yesterday, I was chasing libintl.so.8, rebuilding all ports that got
>>> bumped, checking with libchk for other libintl.so.8 dependencies, and
>>> forcing a rebuild of all these packages: All but two of them had an
>>> indirect dependency on devel/gettext (and I did email the maintainers of
>>> devel/ccrtp and textproc/gsed linking without a dependency).
>>
>> This might be unrealistic but, IMHO, these "indirect dependencies" should
>> not exist. IMHO, there should only be two situations:
>>
>> 1) Port X directly links against or dlopen's libY.so from port Y.
>>
>> In this case, port Y should be listed in LIB_DEPENDS or equivalent
>> for port X and port X will need a portrevision bump and rebuild if
>> the port Y ABI changes (eg a .so version bump)
>>
>> 2) Port X directly links against or dlopen's libZ.so and libZ.so pulls
>> in libY.so from port Y.
>>
>> In this case, port X should not be directly accessing any symbols in
>> libY.so. If the libY.so ABI changes, libZ.so will need to be rebuilt
>> but unless the libZ.so ABI changes, there should be no need to rebuild
>> port X.
>>
>> Are there any other situations that have to be considered?
>
> The problem is a little bit more complex if you have a look at the big
> picture.
>
> Indirect dependencies get hardcoded into binaries in several cases(*1),
> except you use a compiler switch which tells the compile-time-linker to
> not record library dependencies when no symbols of those libs are
> reference directly(*2).
>
> If you want to know which libs are linked into binaries of a port, I
> suggest you have a look at my
> /usr/ports/Tools/scripts/explicit_lib_depends.sh script (note that its
> name starts with "explicit", not with "direct", this is on purpose as
> those two descriptions have a different semantic which is important for
> this discussion).
>
> (*1) Either by libtool as it does not has some hint enabled on FreeBSD,
> or by pkg-config listing them directly even if the corresponding library
> does not reference symbols of such a dependency in its API.
>
> (*2) This is used by some gnome ports (not all), and can not be enabled
> globally, as some programs may depend upon this (e.g. when loading
> plugins which are not linked correctly).

Thanks for your reply and blog posting. With direct and indirect, I was 
refering to package dependencies and not library dependencies.

I have checked one of the missing dependencies with 
explicit_lib_depends.sh, but it did not show up, because 
explicit_lib_depends.sh makes some assumptions upon were binaries reside 
that are not true in this case:

%objdump -x /usr/local/share/examples/telepathy-qt4/call/.libs/call | 
grep NEEDED | grep intl
   NEEDED      libintl.so.9
%pkg_info -W /usr/local/share/examples/telepathy-qt4/call/.libs/call
/usr/local/share/examples/telepathy-qt4/call/.libs/call was installed by 
package telepathy-qt4-0.3.2
%/usr/ports/Tools/scripts/explicit_lib_depends.sh telepathy-qt4-0.3.2
WARNING: your libtool records dependencies recursively, you can not
trust the following output.
QtCore:${PORTSDIR}/devel/qt4-corelib
QtDBus:${PORTSDIR}/devel/dbus-qt4
QtNetwork:${PORTSDIR}/net/qt4-network
QtXml:${PORTSDIR}/textproc/qt4-xml
USE_GNOME+=     _glib20         (devel/glib20)
USE_GNOME+=     libxml2         (textproc/libxml2)
gstinterfaces-0.10:${PORTSDIR}/multimedia/gstreamer-plugins
gstreamer-0.10:${PORTSDIR}/multimedia/gstreamer
telepathy-farsight:${PORTSDIR}/net-im/telepathy-farsight
telepathy-glib:${PORTSDIR}/net-im/telepathy-glib

Thus, explicit_lib_depends.sh cannot be relied upon what to rebuild, 
either -- it missed the same that libchk does. Anyhow, this does not 
matter at all to the main point I tried to raise:

Should _all_ explicit and direct dependencies (to use your vocabulary) 
be accounted for in the LIBDEPENDS of a port? The LIBDEPENDS are used to 
bump PORTREVISIONs to trigger rebuilds. Not having all explicit and 
direct dependencies listed there, reduces the use of PORTREVISION bumps 
so much that their negative side effect (at least when they are not done 
at the same moment as the original commit) becomes dominant (people 
relying on libchk, bsdadminscripts, or the like are forced to rebuild 
ports that are already consistent).

Peter seems to be of my opinion by what he said above, marcus@ did 
introduce USE_GETTEXT for many ports that already have indirect port 
dependencies, so I assume that he agrees, too. On the other hand, pav@ 
(who is among portmgr) seems to disagree (at least a year ago), as I 
stated in my first mail: 
http://lists.freebsd.org/pipermail/cvs-ports/2009-May/172173.html And he 
is not the only one with that opinion.

Yes, the architecture of ports is insufficient for a good solution of 
any kind, but as long as there is not even an agreement, what LIBDEPENDS 
are supposed to contain, following port updates is harder than it should 
be, because of the different strategies used to bump shared libraries 
that affect many ports.

Considering the few responses my posting got, either not many see the 
need to reach an agreement or the posing was not clear or not concise 
enough. (It is not the first time I tried to raise this issue.)

Cheers,
Jan Henrik