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

[b. f.]

>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:
>

Maybe the specific results that you mentioned don't matter, but the
fact that these programs fail to obtain satisfactory results in real
cases, due to some of the complicating factors Alexander mentioned,
_does_ matter -- because if there were a cheap, foolproof method of
determining which ports needed to be updated in all cases, without
introducing further changes in the ports infrastructure, then we could
implement the method in the ports infrastructure, or in portmaster and
portupgrade, and forget about the question that you have raised.


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

It is better in most cases to err on the side of caution and rebuild
too much, than to rebuild too little, and have a broken system.  But
you seem to be conflating two different problems here, as I read it:
the effectiveness of the PORTREVISION bumps is reduced when all direct
dependencies aren't recorded in *_DEPENDS and a simplistic method like
that in ports/Tools/scripts/bump_revision.pl is used to determine
which ports need to be bumped.  But in that case too little is being
rebuilt, not too much.


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

There are some strident portlint warnings that may cause some
maintainers, rightly or wrongly, to add a direct dependency on
devel/gettext, even when there is already an indirect dependency.  So
I wouldn't read too much into J. Marcus' actions.  I suspect that Pav
is weighing the costs of refactoring all of the *_DEPENDS in Ports to
follow what you seem to be suggesting, and the added overhead of
processing more dependencies during builds, versus the concern that a
few users are going to have trouble during major upgrades if they are
building from source on a running system (this doesn't seem to be a
problem on tinderboxes and package-building clusters), and finding
that it isn't worth the effort from his perspective.  With the current
practice, all dependencies may not be correctly recorded as direct
dependencies, but at least (barring some other mistakes) they _are_
recorded.

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

Just because one thinks that, ideally, LIB_DEPENDS should contain all
direct library dependencies, and that such a change may help resolve
some problems, doesn't necessarily mean that one thinks that, in
practice, all of them should be added -- because there is a cost to
doing so. In principle, I agree with what I think that you are
suggesting, that they should be added, but I can see why others may be
hesitant to do this, and I haven't tried to estimate the added
overhead on a system with a lot of ports.

b.