Date: Tue, 1 Jun 2010 09:03:18 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Jan Henrik Sylvester <me@janh.de> Cc: ports-list freebsd <freebsd-ports@freebsd.org> Subject: Re: Direct or indirect libdependencies (using the libintl.so.8 case) Message-ID: <AANLkTin8RIvE7KQV49sj0xR66Y9F6eACXj6z7Jiy4wie@mail.gmail.com> In-Reply-To: <4C04CAAA.7080001@janh.de> References: <4C04CAAA.7080001@janh.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 1, 2010 at 1:54 AM, Jan Henrik Sylvester <me@janh.de> wrote: > 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. I think that devel/gettext is an unfortunate exception to the rule as it infects everything under the sun with its `international catalog support'. I haven't done portmaster -af in a long time, but unfortunately some things aren't working as expected (gthumb segfaults on certain directories), so here we go... -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTin8RIvE7KQV49sj0xR66Y9F6eACXj6z7Jiy4wie>