Date: Sun, 02 Aug 2009 09:48:08 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-ports@freebsd.org Subject: Re: ports/*/jpeg "Thanks a lot guys" Message-ID: <4A7552C8.7020508@infracaninophile.co.uk> In-Reply-To: <20090801224323.GA65040@server.vk2pj.dyndns.org> References: <20090731173636.GA76357@owl.midgard.homeip.net> <20090731121249.538ea7e7.jasonh@DataIX.net> <20090731173636.GA76357@owl.midgard.homeip.net> <4A740679.1020608@infracaninophile.co.uk> <c/bsZ0e9iU@dmeyer.dinoex.sub.org> <4A747C77.1040800@infracaninophile.co.uk> <20090801224323.GA65040@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA38550551EACD25E436E94C5
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Peter Jeremy wrote:
> [I was also dismayed when I saw the bump].
>=20
> On 2009-Aug-01 18:33:43 +0100, Matthew Seaman <m.seaman@infracaninophil=
e.co.uk> wrote:
>> You could, for instance, run ldd(1) against each of the files a port i=
nstalls
>> 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 librar=
ies
>> linked against.
>=20
> 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).
Yes. There's also a problem with ports like firefox and openoffice that
dynamically link against shared libraries not on the usual LD_LIBRARY_PAT=
H.
Still, what I wrote is still useful as a tool for providing a starting po=
int
on recording shared library dependencies.
>> Or you could resolve the shlib filenames back to the ports
>> that supply them, and create a 'SHLIB_PORTS_NEEDED' variable in the po=
rt
>> Makefiles.
>=20
> 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.
I considered this, but didn't think it would be as complete as using ldd(=
1).
Maybe I was wrong there -- but I've still a nagging feeling that this wil=
l miss
out some cases. Also, LIB_DEPENDS only covers the first generation depen=
dencies
-- if your shared library itself depends on another shared library, that =
data
would have to be accounted for by recursing through the dependency tree. =
(Your
case (2) below)
This is all doable: INDEX generation does virtually the same thing with
BUILD_DEPENDS and RUN_DEPENDS. In fact, adding another field to the INDE=
X
showing shlib dependencies would be a handy way of making the data access=
ible.
> 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.
>=20
> This is slighly more complex than
> cd /usr/ports && \
> for i in */*; do [ -d "$i" ] && cd "$i" && make all-depends-list ; do=
ne | \
> 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 th=
e
> 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.
>=20
> 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 proces=
ses
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 cumulat=
ively.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enigA38550551EACD25E436E94C5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkp1Us4ACgkQ8Mjk52CukIznZACfQ4KePmhn448arixdKUMBjgXN
KEEAn1iXSkFJPUv20+dggGNK3GBdWk0O
=HN0C
-----END PGP SIGNATURE-----
--------------enigA38550551EACD25E436E94C5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A7552C8.7020508>