ports/*/jpeg "Thanks a lot guys"

[Matthew Seaman]

Doug Barton wrote:
> Garrett Cooper wrote:
> 
>> 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 :)?
> 
> 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?  

Showing direct vs indirect linkage seems to be what 'ldd -a' does, although
I think given the above you'ld have to rebuild anything that linked, directly
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 maintainers
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).
> 
> 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. 

> That said, if anyone really really wants to pursue the dependency
> graphing issue further, can I suggest a new thread focused on that topic?

What's wrong with the thread we've already got?

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20090804/0e954b5d/signature.pgp