ports/*/jpeg "Thanks a lot guys"

Garrett Cooper yanefbsd at gmail.com
Mon Aug 3 09:11:14 UTC 2009


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 :)?

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.

Thanks,
-Garrett


More information about the freebsd-ports mailing list