ports/*/jpeg "Thanks a lot guys"

[Peter Jeremy]

[I was also dismayed when I saw the bump].

On 2009-Aug-01 18:33:43 +0100, Matthew Seaman <m.seaman at infracaninophile.co.uk> wrote:
>You could, for instance, run ldd(1) against each of the files a port installs
>and then record in /var/db/pkg/portname-1.2.3/+SHLIBS or equivalently in the
>.tbz package tarball a sorted and uniq'd list of all the shared libraries
>linked against.

Unfortunately, this isn't sufficient because a non-trivial number of
ports dlopen() libraries rather than directly linking against them.
(The Xorg server is probably the most widely used culprit here).

>  Or you could resolve the shlib filenames back to the ports
>that supply them, and create a 'SHLIB_PORTS_NEEDED' variable in the port
>Makefiles.

A third approach is to more carefully recurse through the dependency
tree: Given A depends on B depends on C, B only needs bumping if it
LIB_DEPENDS on A and C only needs bumping if it LIB_DEPENDS on B and
B was bumped.

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.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20090801/8ab5bd3b/attachment.pgp