Doug Barton wrote:
Garrett Cooper wrote:Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) has a script called `revdep-rebuild' which goes and runs ldd on all pieces of software that are installed in portage (ok, substitute ports here). What I'm driving at is that we can use pkg_info and/or the mtree generated files to determine what files are installed, find out which packages have been broken up an update, then rebuild the port and all dependencies (LIB_DEPENDS?). What say you to that :)?I was experimenting with various scripts using ldd in parallel to my most recent portmaster update and I think there is a problem with that solution. If libA is linked against libB which in turn is linked against libMISSING (such as libjpeg.so.9 for example) then ldd against libA will show libMISSING even though that problem can be solved by simply updating libB (i.e., without recompiling libA). This same issue applies to the idea of running ldd against things at install time and recording the list.
Is that sufficient? If the ABI changes to libMISSING change its size such that it uses a different number of 4k memory pages, doesn't thatchange the load address of any subsequently loaded shlibs?
Showing direct vs indirect linkage seems to be what 'ldd -a' does, although I think given the above you'ld have to rebuild anything that linked, directly or indirectly, against libMISSING.
Perhaps someone smarter than I about ldd can come up with a solution to this, but until then I think that using ldd after the fact is a stopgap measure to repair things if the ports infrastructure fails us.
A script for scanning the ldd(1) output would be useful for port maintainers primarily IMHO.
In theory the dependency graphing in our existing ports infrastructure should deal with this problem. In practice at the moment I personally feel that we record too many "indirect" dependencies (such as libA above) and that we would serve our users better if we stuck to direct dependencies only (libB in the example above). What should have happened in this case is that the ports that depend DIRECTLY on libjpeg should have had their revisions bumped at the same time as the update to libjpeg. Since that is what usually happens, hopefully we can stop flogging this horse soon.
What usually seems to happen is that any port with a RUN_DEPENDS on the port providing the shlib in question gets a portrevision bump, including many where it makes no sense to do so. Tracking LIB_DEPENDS would be my choice for dealing with this problem, but as you say, there would needto be a ports-wide review and rationalisation of LIB_DEPENDS settings.
That said, if anyone really really wants to pursue the dependency graphing issue further, can I suggest a new thread focused on that topic?
What's wrong with the thread we've already got?
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
