Garrett Cooper wrote: > On Sun, Aug 2, 2009 at 7:52 AM, Matthew > Seaman<m.sea...@infracaninophile.co.uk> wrote: >> Matthew Seaman wrote: >> >>> Peter Jeremy wrote: >>>> In this specific case, p5-RT-* depends on www/rt38 depends on >>>> graphics/p5-GD depends on graphics/gd depends on graphics/jpeg. When >>>> jpeg is bumped, gd needs to be bumped because it LIB_DEPENDS on jpeg. >>>> p5-GD then needs to be bumped because it LIB_DEPENDS on gd. rt38 does >>>> not need to be bumped because it has no LIB_DEPENDS on p5-GD. p5-RT-* >>>> does not need to be bumped because rt38 is not bumped. >>>> >>>> This is slighly more complex than >>>> cd /usr/ports && \ >>>> for i in */*; do [ -d "$i" ] && cd "$i" && make all-depends-list ; done >>>> | \ >>>> grep jpeg >>>> because you need to actually follow the dependency tree, but is not >>>> impractical. The only issues I can see with this approach are: >>>> 1) Mapping the shared library reported by 'make lib-depends' back to the >>>> port than installs it. >>>> 2) You are relying on LIB_DEPENDS being correct: In my general example >>>> above, if A is missing a LIB_DEPENDS on C, this may not be detected >>>> in the build process because of the implicit dependency on C via B. >>>> >>>> No sample script because I'm not sure of the correct approach to 1) off >>>> the top of my head. >>> Doing (1) using my p5-FreeBSD-Portindex code is pretty easy. It's about >>> time I released an update anyhow -- I'll code up a little app that >>> processes >>> the LIB_DEPENDS linkages already stored in the cache and lists each port >>> that has a LIB_DEPENDS, together with all the ports it depends on >>> cumulatively. >> I've got this working now -- I still need to do some more testing, update >> documentation and stuff before I release version 2.2 of >> p5-FreeBSD-Portindex, >> but as a taster, here's the result of generating this on my machine just >> now: >> >> http://www.infracaninophile.co.uk/SHLIBS.bz2 >> >> (Note that this includes the effect of a number of local settings in >> /etc/make.conf) >> >> It's similar to the ports INDEX file, when decompressed. There's one row of >> the file for each port, and each row contains 3 fields separated by '|' >> characters: >> >> package-name|port/origin|space separated list of lib_depends port origins >> >> So, to extract the list of ports depending on www/jpeg: >> >> happy-idiot-talk:/tmp:% grep graphics/jpeg SHLIBS | cut -d '|' -f 1-2 | head >> -10 >> accerciser-1.6.1_1|/usr/ports/accessibility/accerciser >> at-poke-0.2.3_4|/usr/ports/accessibility/at-poke >> at-spi-1.26.0_1|/usr/ports/accessibility/at-spi >> dasher-4.10.1_1,2|/usr/ports/accessibility/dasher >> gnome-mag-0.15.8|/usr/ports/accessibility/gnome-mag >> gnopernicus-1.1.2_6|/usr/ports/accessibility/gnopernicus >> gok-2.26.0_1,1|/usr/ports/accessibility/gok >> kdeaccessibility-3.5.10_2|/usr/ports/accessibility/kdeaccessibility >> kdeaccessibility-4.2.4_1|/usr/ports/accessibility/kdeaccessibility4 >> mousetweaks-2.26.3_1|/usr/ports/accessibility/mousetweaks >> >> Again, this has a number of deficiencies. For instance, programs that >> embed a perl interpreter will link against libperl.so => >> /usr/local/lib/perl5/5.10.0/mach/CORE/libperl.so, but none of them register >> a LIB_DEPENDS on lang/perl5.10. [See for example net-mgmt/net-snmpd, >> www/mod_perl2] >> >> Similarly, programs that declare 'USE_MYSQL=NN' will have a LIB_DEPENDS on >> libmysqlclient.so.X added to their dependency mix even if they contain >> no compiled ELF binaries [See net-mgmt/cacti databases/phpmyadmin] >> >> However, I think that the deficiencies are not too intractable to fix, >> and this approach shows some promise. > > There actually may be a much easier solution to this problem. > > 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 :)? > > If no one cares about the language, I can whip up a really quick > python script which solves this problem and we can migrate to a more > longterm solution in bourne shell if desired.
If it's going to scan *all* of the installed files known to the pkg
database to identify packages that depend on a particular shared library
then it's going to take a pretty long time to run on a typical desktop
package load.
It would make sense to scan the installed files at package installation
time and cache the result for each installed package, which is pretty
much where I was at with the Bourne shell script I posted up-thread.
There was a question about apps that use dlopen() to load libraries,
rather than letting ld.so do the work for them. I don't think that
using ldd(1) will pick up any app that does that, but then again I
don't know if this is a widespread practice, and if it is, whether there
is any simple way to pick out packages that need reinstallation because
of it other than by using manually defined LIB_DEPENDS settings in port
Makefiles.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. Flat 3
7 Priory Courtyard
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW, UK
signature.asc
Description: OpenPGP digital signature
