Date: Sat, 01 Aug 2009 18:33:43 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Dirk Meyer <dirk.meyer@dinoex.sub.org> Cc: freebsd-ports@freebsd.org Subject: Re: ports/*/jpeg "Thanks a lot guys" Message-ID: <4A747C77.1040800@infracaninophile.co.uk> In-Reply-To: <c/bsZ0e9iU@dmeyer.dinoex.sub.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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC8EAB2C9A96EAF4D077532E6
Content-Type: multipart/mixed; boundary="------------090403000206040402040901"
This is a multi-part message in MIME format.
--------------090403000206040402040901
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Dirk Meyer wrote:
> Hallo Matthew Seaman,
>=20
>> The OP does have a valid point though. I just got an e-mail from Fres=
hpo=3D
>> rts
>> saying that a bunch of ports I maintain had had PORTREVISION bumps bec=
aus=3D
>> e of
>> the jpeg update. Which is all fine and dandy, except that these were =
the=3D
>> =3D20
>> www/p5-RT-* extension modules for RT. First of all, they are pure per=
l: =3D
>> there's
>> no object linkage with the jpeg shlibs at all. Secondly, they have no=
thi=3D
>> ng
>> to do with manipulating jpeg data in any way, shape or form. One of t=
hei=3D
>> r
>> dependencies links against libjpeg: that's it.
>=20
> This may be, but the port has "libjpeg" as dependency listed.
>=20
> ports/www/p5-RT-Authen-ExternalAuth$ make all-depends-list | grep jpeg
> /usr/ports/graphics/jpeg
>=20
> ports/www/p5-RT-Extension-SLA$ make all-depends-list | grep jpeg
> /usr/ports/graphics/jpeg
Yeah. That's because p5-RT-* {run-,build-} depend on www/rt38, and www/r=
t38
depends on graphics/p5-GD, which depends on graphics/gd, which depends on=
=20
graphics/jpeg.
Of that whole dependency chain only graphics/gd and graphics/p5-GD need
a PORTREVISION bump due to the libjpeg update.
> Sorry I had no way to detect if this dependecy is not needed.
> I build the index with "EXPLICIT_PACKAGE_DEPENDS=3Dyes",
> which reduced the number of ports affected alot.
>=20
> Sadly further work on this general problem has been suspended.
>=20
> I hoped the current package tools where up to the task,
> making this bump obsolete, but I have been prooven wrong.
>
Absolutely. I don't what to come over as if I'm complaining about ports
I maintain in particular -- it's the general problem of finding ports tha=
t
are affected by a shlib bump which I think needs a better solution.
It seems to me that the necessary data to construct an appropriate invers=
e
dependency graph is simply not extracted anywhere, so port management too=
ls
just don't have the wherewithal they need to solve this problem.
You could, for instance, run ldd(1) against each of the files a port inst=
alls
and then record in /var/db/pkg/portname-1.2.3/+SHLIBS or equivalently in =
the
=2Etbz package tarball a sorted and uniq'd list of all the shared librari=
es
linked against. Or you could resolve the shlib filenames back to the por=
ts
that supply them, and create a 'SHLIB_PORTS_NEEDED' variable in the port
Makefiles. Hmmm.... The attached script is a bit slow, and it doesn't=20
cope with linux executables but it shows the general idea. eg:
% ./shlib-ports-needed.sh php5-gd-5.2.10=20
print/freetype2
graphics/jpeg
x11/libX11
x11/libXau
x11/libXdmcp
x11/libXpm
x11/libxcb
graphics/png
devel/t1lib
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
--------------090403000206040402040901
Content-Type: text/plain;
name="shlib-ports-needed.sh"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="shlib-ports-needed.sh"
IyEvYmluL3NoCgojIEAoIykgJElkJAojCiMgR2l2ZW4gYSBwa2duYW1lIHNjYW4gYWxsIG9m
IHRoZSBmaWxlcyBpbnN0YWxsZWQgYnkgdGhlIHBhY2thZ2UsCiMgYW5kIGNyZWF0ZSBhIGxp
c3Qgb2YgYWxsIG9mIHRoZSBzaGxpYnMgbGlua2VkIHRvIGJ5IGFueSBleGVjdXRhYmxlcwoj
IG9yIHNobGlicyBmcm9tIHRoYXQgcGFja2FnZS4KIwoKUEFUSD0vdXNyL2JpbjovYmluOi91
c3Ivc2Jpbjovc2JpbiA7IGV4cG9ydCBQQVRICklGUz0nIAkKJyA7IGV4cG9ydCBJRlMKdW1h
c2sgMDIyCgpwa2duYW1lPSR7MT8nUGxlYXNlIHN1cHBseSB0aGUgbmFtZSBvZiBhbiBpbnN0
YWxsZWQgcGFja2FnZSd9CmxkZGNtZD0iIgoKVE1QPSQoIG1rdGVtcCAtdCAiJCggYmFzZW5h
bWUgJDAgKS5YWFhYWFgiICkKaWYgWyAkPyAtbmUgMCBdOyB0aGVuCiAgICBlY2hvICIkMDog
RkFUQUwgQ2FuJ3QgY3JlYXRlIHRlcG9yYXJ5IGZpbGUiCiAgICBleGl0IDEKZmkKdHJhcCAi
cm0gJFRNUCAmJiBleGl0IiBFWElUIElOVCBLSUxMCgpmb3IgZiBpbiAkKCBwa2dfaW5mbyAt
cUx4ICRwa2duYW1lICkgOyBkbwogICAgbGRkIC1mICIlcFxuIiAkZiAyPi9kZXYvbnVsbCA+
PiAkVE1QCmRvbmUKCnBrZ2xpc3Q9JCggZm9yIGYgaW4gJCggc29ydCAtdSAkVE1QICkgOyBk
byBwa2dfaW5mbyAtcVcgJGYgOyBkb25lIHwgc29ydCAtdSApCgpmb3IgZiBpbiAkcGtnbGlz
dCA7IGRvCiAgICBwa2dfaW5mbyAtcW8gJGYKZG9uZQoKIwojIFRoYXQncyBBbGwgRm9sa3Mh
CiMK
--------------090403000206040402040901--
--------------enigC8EAB2C9A96EAF4D077532E6
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
iEUEAREIAAYFAkp0fH0ACgkQ8Mjk52CukIwaTACXWV2KbKiVnPoZZALx71If9hDS
AQCeII16DmxmQCRD+Qco9a5PS0z4P4Q=
=kPeg
-----END PGP SIGNATURE-----
--------------enigC8EAB2C9A96EAF4D077532E6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A747C77.1040800>