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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
