ports/*/jpeg "Thanks a lot guys"

[Emanuel Haupt]

> On Sun, Aug 2, 2009 at 7:52 AM, Matthew
> Seaman<m.seaman at 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 :)?

sysutils/bsdadminscripts provides a script called pkg_libchk which does
a similar thing.

Emanuel