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

[Jan Henrik Sylvester]

The general argument follows below, I just need some anecdotal evidence 
first:

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).

Then I did a complete scan for libintl.so.8 and found one file linking 
libintl.so.8 that was outside the path that libchk scans (
share/examples/telepathy-qt4/call/.libs/call from net-im/telepathy-qt4). 
Yes, 'portupgrade -fr' would have been better as suggested in UPDATING.

So far, no surprise.

Now, many ports got bumped adding a direct dependency that already have 
an indirect one. These got rebuild yesterday, either by checking with 
libchk or by following UPDATING and rebuilding all (indirect) 
dependencies, and now have to be rebuild, again. To me, the new bump 
seems to be a waste, since AFAIU indirect and direct dependencies are 
not listed in the package any different.

If bumping portrevisions would be done consequently -- for example by 
the build cluster recording libdependencies somehow that can be used as 
a basis for bumps -- it would help updating, but currently, bumping some 
portrevisions does not seem to help and only causes rebuilds being 
wasted as in this case.

Moreover, there does not seem to be an agreement, if direct 
libdependencies should be listed with indirect already existing. Several 
just got them added for gettext, but when I asked for one to be 
introduced on another occasion, it got removed shortly afterward again 
with pav@ explaining to me that they are not desirable: "We should not 
explicitly state any indirect dependencies of any kinds. For the sake of 
simplicity." This was the commit: 
http://lists.freebsd.org/pipermail/cvs-all/2009-May/288801.html -- I do 
not see a difference to the current case.

I think that libdependencies should be recorded for making portrevision 
bumps consistent -- either by trying to introduce direct 
libdenpendencies for every port that links a shared library or by 
recording real shared library dependencies externally (maybe by the 
build cluster).

Currently, sometimes all direct and indirect portrevisions are bumped, 
sometimes only the direct ones, and sometimes none at all -- in the 
second and third case with instructions in UPDATING to rebuild 
recursively. For one of my machines, I can use libchk to occasionally 
check if something is left behind, but for all of the machines I 
transfer packages to, I keep recording lists of packages that need a 
forced rebuild. I somehow feel that that should be an automated task 
(done by the ports framework itself).

Strictly following UPDATING seems to me not always to be save, either: 
If I waited a few weeks and I am told to do two recursive rebuilds (that 
are not forced), the second one could miss some portrevision bumps, 
because the first one already produced up-to-date ports. If the second 
one was due to a shared library bump, I would be in an inconsistent 
state. Sometimes, I really wonder about the order in which to follow 
instructions in UPDATING -- and I am pretty sure that there is not 
always an order that gives a save result: the example I just gave with 
several portrevision bumps due to shared library bumps not depending on 
each other but with common ports dependent on them cannot be solved, I 
guess. Then tools like libchk (or bsdadminscripts) are the only help, 
but since they cannot find all libdependencies (dlopen), they are not an 
universal solution, either (but seem to have a high rate of success).

My first argument is for portrevision bumps, my second one seems to be 
against them. Both approaches seem to have trade-offs, I wish one would 
be followed consistently. I know that the decisions are made on a 
case-by-case basis, but for my taste, it is too much case-by-case.

Cheers,
Jan Henrik