On P, 2008-11-09 at 18:34 +0200, Peter Alfredsen wrote:
> On Sunday 09 November 2008, Fabian Groffen wrote:
> > On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
> > > + # If this is a non-ELF system, chances are good that the .la
> > > files will be needed. + if type -P scanelf &> /dev/null
> >
> > I think this is a not so cool way to check for an ELF system.
>
> Indeed, I think it's a horrid way. Please find a better one.
>
> > > + then
> > > + debug-print "Scanelf found, proceeding..."
> > > + ebegin "Removing useless .la files"
> > > + find "${TARGET}" -name '*.la' '(' -type l -o -type f ')' -exec
> > > rm -f '{}' '+' + eend 0
> > > + else
> > > + debug-print "scanelf not found, this appears to be a non-ELF
> > > system." + debug-print "non-ELF systems are likely to need
> > > .la
> > > files." + debug-print ".la files not removed from ${TARGET}"
> >
> > rationale?
>
> "I've been told" that .la files are really only needed on non-ELF
> systems and with plugin systems that use dlopen. I actually have no way
> of knowing that the .la files are needed on those arches, but I had
> your archs in mind when doing the patch.I heavily object to having any such function introduced or used or equivalent .la removals conducted without a good rationale and explanation of why this is the approach taken. I see no such explanation anywhere, you are just blatantly removing .la files that the package itself installs, with no good way to ensure they aren't actually needed by libltdl and breaking revdep-rebuild heavily when used unwisely. If such a function is introduced, I'm quite sure it will get used by some maintainers in revbumps or version bumps, when the library soname has not changed at all compared to the previous version. What that means is that the user will get absolutely all packages suggested to revdep-rebuild that directly OR _indirectly_ rdepend on the library in question. Therefore to have any relatively safe way to add this, you can only add the call when the library introduced ABI breaks. Some libraries are backwards compatible forever, in effect you can't ever add epunt_la_files to those without causing some serious one-time pain for users. Therefore this is not a proper solution, and I don't see why this should be used for just a small set of packages that do have an unstable ABI while not having a solution for all the rest. Additionally, I am quite unconvinced on the coverage of the removal or non-removal of the files. Not removing it on all platforms (because you can't) also doesn't solve the problem for those non-ELF platforms - you still will get all the pain you are trying to solve here on those platforms. Also, this would be a local Gentoo specific hack to reduce pain on ELF systems, while I'm sure there are upstream or better solutions available that have not been explored. Here are two different ideas of mine for libtool upstream work to perhaps solve this: * Get libtool to not include indirectly linked libraries as dependencies in the .la files if it is running on an ELF system (additionally I think libtool should have a much better idea if a platform is ELF or not) * Make libtool not install .la files on ELF platform if it doesn't see libltdl used These are just two different ideas, that might not work out, but one of them might (they are mutually exclusive though). Ideas like these should be investigated and pursued instead of distro specific hacks, such as epunt_la_files. I do however think that it would be a good idea to tweak revdep-rebuild to not take indirect dependencies listed in .la files too seriously, and mostly just go by DT_NEEDED entries in ELF files on ELF systems instead of all of the listed ones in .la ones, as even if a solution for upstream libtool is figured out, we'd still have old installed .la files around that include indirect libraries. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
