Direct or indirect libdependencies (using the libintl.so.8 case)
Jan Henrik Sylvester
me at janh.de
Fri Jun 4 13:35:10 UTC 2010
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
> 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
%pkg_info -W /usr/local/share/examples/telepathy-qt4/call/.libs/call
/usr/local/share/examples/telepathy-qt4/call/.libs/call was installed by
WARNING: your libtool records dependencies recursively, you can not
trust the following output.
USE_GNOME+= _glib20 (devel/glib20)
USE_GNOME+= libxml2 (textproc/libxml2)
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.)
More information about the freebsd-ports