On K, 2008-11-12 at 15:40 +0100, Peter Alfredsen wrote: > 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.
Unless a system happens to have USE=static used for a few lower level indirect dependencies (and those very low level libraries having such an option is sometimes, albeit rarely, quite cool for embedded use cases). It just breaks then according to other subthreads, and you have no way to really check for that in your utility function. > > 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 . There is still no solution for things that do not break ABI, but get rebuilt with different USE flags, for example the USE=esd fiasco where to get rid of esound you had to remove USE=esd and rebuild many packages with revdep-rebuild for no reason other than libtool being stupid. This stupidity should be fixed, not delayed with workarounds to a small subset of cases. > 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. Or if libtool would be fixed to not cause that pain in the first place.. > fix_libtool_files.sh also doesn't play nice with .la files and will > leave orphan .la files around. That's something that can be fixed. > 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. I do worry about projects that make us better than other distributions, by being able to do things that are not possible elsewhere. > 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. It is the worst solution to a problem out of different possibilities for a solution - that should be enough. If not, well, I guess I'll have to suffer with the consequences of weird problems we have not discovered yet and a suboptimal solution making a proper one not happen anytime soon. No, I do not have time to look into implementing something proper in libtool before a couple of weekends. > > 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. Fixed and generalized fix_libtool_files.sh or fixed libtool? -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
