Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[Peter Alfredsen <loki_val@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4369 bytes --]

On Wednesday 12 November 2008, Mart Raudsepp wrote:

> 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.

It's a utility function. I've done all I can to ensure it'll be used 
wisely. Whether it is used wisely is between you and ( $ROOT or $666 ). 
But let me point out that in most leaf-packages, removing la files will 
cause no pain, but will ensure that they do not have to be rebuilt if 
a .la-listed dependency loses its .la file.

> 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.

Because having la files will automagically provide the equivalent amount 
of pain such as in http://bugs.gentoo.org/245889 .
We talked about this on #gentoo-dev the other day. 200 packages out of 
1000 on my system had to be rebuilt because of this. If libxcb didn't 
use la files, that wouldn't have been necessary for the majority of 
those. If the packages themselves didn't use la files, it wouldn't have 
been necessary either.

fix_libtool_files.sh also doesn't play nice with .la files and will 
leave orphan .la files around.

In other words, it's no a question of IF .la files will break stuff but 
WHEN they will break stuff. And how BIG the breakage will be. We can 
remedy the last part by having leaf packages not install .la files and 
by punting library .la files when a .so bump occurs or (as in the case 
of libxcb) when other .la-related breakage occurs.

(Who doesn't remember "The Day the Build Servers were Silenced..." )
http://bugs.debian.org/354674

> 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.

As those platforms are still not supported by Gentoo as such, but by the 
Gentoo/Alt project, that is not really a problem we should be worrying 
about. That part of the function is a good-faith effort to not 
unnecessarily break stuff for Gentoo/Alt users, nothing more. If they 
later discover that some of their non-ELF platforms can do without .la 
files, they can just wiggle the code and make it so.

> 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:
[Snip good ideas]

Plz2implent. Kthxbye.

But you've still not given a good reason why this function in itself is 
bad.

> 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.

That would cause breakage. There's a reason why revdep-rebuild rebuilds. 
Libtool will look for those la files and fail the compile.

-- 
/PA

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]