Date: Fri, 4 Jun 2010 19:59:03 +0000 From: "b. f." <bf1783@googlemail.com> To: Jan Henrik Sylvester <me@janh.de> Cc: freebsd-ports@freebsd.org Subject: Re: Direct or indirect libdependencies (using the libintl.so.8 case) Message-ID: <AANLkTikpsvSJUJpueSiGuXzcZdoom8kAANzTZgSk__ll@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
>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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikpsvSJUJpueSiGuXzcZdoom8kAANzTZgSk__ll>