Apparently, though unproven, at 16:17 on Thursday 19 May 2011, Paul Hartman did opine thusly:
> On Wed, May 18, 2011 at 4:53 PM, Mick <michaelkintz...@gmail.com> wrote: > > On Wednesday 18 May 2011 22:28:38 Alan McKinnon wrote: > >> Apparently, though unproven, at 23:06 on Wednesday 18 May 2011, Mick did > >> opine > >> > >> thusly: > >> > Had a depclean session which removed: > >> > media-libs/musicbrainz > >> > > >> > selected: 2.1.5 > >> > > >> > protected: none > >> > > >> > omitted: 3.0.2 > >> > > >> > Then I followed up with revdep-rebuild and this comes up: > >> > * Generated new 1_files.rr > >> > * Collecting complete LD_LIBRARY_PATH > >> > * Generated new 2_ldpath.rr > >> > * Checking dynamic linking consistency > >> > > >> > [ 67% ] * broken /usr/lib/libtunepimp.la (requires -lmusicbrainz) > >> > [snip ...] > >> > > >> > * Assigning files to packages > >> > * !!! /usr/lib/libtunepimp.la not owned by any package is broken !!! > >> > * /usr/lib/libtunepimp.la -> (none) > >> > > >> > What is "-lmusicbrainz" and is it telling me to just delete > >> > /usr/lib/libtunepimp.la? > >> > >> Look into any *.la file and you will see stuff like this: > >> > >> /usr/lib/libsqlite3.la:dependency_libs=' -ldl -lpthread' > >> > >> The .la files are hints to the linker telling it how to do stuff, the -l > >> bits reference libraries that will be needed. Far more often than is > >> acceptable, libtool cocks this up in spectacular ways, which is why we > >> had > >> > >> lafilefixer --justfixit > >> > >> for so long, and why it is now built into portage. > >> > >> I have musicbrainz, but I do not have /usr/lib/libtunepimp.la and yours > >> is orphaned anyway - it probably got left behind long ago when depclean > >> didn't know it was related to musicbrainz. > >> > >> Just delete the thing, be done with it, revdep-rebuild will stfu and you > >> will be a much happier chappy > > > > Thanks guys, it's been blitzed! > > I think the long-term plan is to eliminate the *.la files entirely, > once all packages have been updated as such by their maintainers, so > hopefully this kind of problem will vanish in the not-too-distant > future. :) It's closer than you might think, there are very few packages left to be fixed: http://blog.flameeyes.eu/2011/05/03/surviving-without-libtool-archives -- alan dot mckinnon at gmail dot com