Date: Tue, 04 Aug 2009 07:31:38 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Doug Barton <dougb@FreeBSD.org> Cc: Garrett Cooper <yanefbsd@gmail.com>, freebsd-ports@FreeBSD.org, Peter Jeremy <peterjeremy@optushome.com.au> Subject: Re: ports/*/jpeg "Thanks a lot guys" Message-ID: <4A77D5CA.3090304@infracaninophile.co.uk> In-Reply-To: <4A7724A7.6000500@FreeBSD.org> References: <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> <4A7552C8.7020508@infracaninophile.co.uk> <4A75A813.10307@infracaninophile.co.uk> <7d6fde3d0908030148h3b5a5934lb0ade13d8b095105@mail.gmail.com> <4A7724A7.6000500@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig13F4B409410B086897D3BB66
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Doug Barton wrote:
> Garrett Cooper wrote:
>=20
>> 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 :)?
>=20
> I was experimenting with various scripts using ldd in parallel to my
> most recent portmaster update and I think there is a problem with that
> solution. If libA is linked against libB which in turn is linked
> against libMISSING (such as libjpeg.so.9 for example) then ldd against
> libA will show libMISSING even though that problem can be solved by
> simply updating libB (i.e., without recompiling libA). This same issue
> applies to the idea of running ldd against things at install time and
> recording the list.
Is that sufficient? If the ABI changes to libMISSING change its size
such that it uses a different number of 4k memory pages, doesn't that
change the load address of any subsequently loaded shlibs? =20
Showing direct vs indirect linkage seems to be what 'ldd -a' does, althou=
gh
I think given the above you'ld have to rebuild anything that linked, dire=
ctly
or indirectly, against libMISSING.
> Perhaps someone smarter than I about ldd can come up with a solution
> to this, but until then I think that using ldd after the fact is a
> stopgap measure to repair things if the ports infrastructure fails us.
A script for scanning the ldd(1) output would be useful for port maintain=
ers
primarily IMHO.
> In theory the dependency graphing in our existing ports infrastructure
> should deal with this problem. In practice at the moment I personally
> feel that we record too many "indirect" dependencies (such as libA
> above) and that we would serve our users better if we stuck to direct
> dependencies only (libB in the example above).
>=20
> What should have happened in this case is that the ports that depend
> DIRECTLY on libjpeg should have had their revisions bumped at the same
> time as the update to libjpeg. Since that is what usually happens,
> hopefully we can stop flogging this horse soon.
What usually seems to happen is that any port with a RUN_DEPENDS on the
port providing the shlib in question gets a portrevision bump, including
many where it makes no sense to do so. Tracking LIB_DEPENDS would be
my choice for dealing with this problem, but as you say, there would need=
to be a ports-wide review and rationalisation of LIB_DEPENDS settings.=20
> That said, if anyone really really wants to pursue the dependency
> graphing issue further, can I suggest a new thread focused on that topi=
c?
What's wrong with the thread we've already got?
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
--------------enig13F4B409410B086897D3BB66
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
iEYEAREIAAYFAkp31dAACgkQ8Mjk52CukIzAFQCfUgqe/l+5FFaGrgDSYvtlCJq/
7GEAn04wOqnEvxAgFYNrj8UoC/VW8IIH
=8D1y
-----END PGP SIGNATURE-----
--------------enig13F4B409410B086897D3BB66--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A77D5CA.3090304>