Flameeyes's Weblog comments

"Again about .la files (or why should they be killed off sooner rather than later)" by Flameeyes

Thu, 03 Jul 2008 20:13:56 +0000

I think you have a bit of confusion about libraries. At any rate, I’ve fixed it quite easily, I’ll post something later tomorrow most likely.

"Again about .la files (or why should they be killed off sooner rather than later)" by givemesugarr@gmail.com

Thu, 03 Jul 2008 19:55:29 +0000

i’ve found a good and interesting way of getting rid of the xcb failures. first of all try rebuilding the packages you need to rebuild and a whole bunch of them will build in the correct way. the packages that fail need to be manually uninstalled, then reinstalled after removing their remnants by hand. this time pkg-config and libtool will work in the right way and find out that they really don’t need the la files. if they still need it (there are 2 or 3 packages that still need them) then the problem is that these packages build static shared libs. so just remove the static shared and make them to be dinamically linked (i still don’t understand why a system as gentoo doesn’t still take into consideration the full removal of static shared libs). of course—as-needed helps very much containing the rebuild, but you should also control that some packages have static .la that still point to the incorrect xcb .la. from the x11 overlay i’ve also found out that the protos and the majority of libs are very stable. i’m now using it to its fullness and have a much more stable system than gentoo’s stable amd64 branch.

"Blast from the recent past; two years ago" by Flameeyes

Thu, 03 Jul 2008 12:45:16 +0000

Two years ago Dan Armak gone MIA without no announce, KDE team ended up being headless. And we were quite a few less people than it is now. Yet we managed to handle everything.

So please don’t start with the crap of “you removed the lead and now it’s crap” … it’s not requiring a LEAD to just get a patch for kopete in.

"Blast from the recent past; two years ago" by Thomas Anderson

Thu, 03 Jul 2008 10:38:18 +0000

Maybe the reason the KDE team has yet to fix that is because the lead was forcibly retired without any notice whatsoever?

And I disagree with Tester, KDE is certainly not a failed project, it’s very much alive and kicking, and getting more polished by the day.

"Blast from the recent past; two years ago" by Merlin

Thu, 03 Jul 2008 08:06:49 +0000

I don’t think KDE or out of kernel drivers is wasted time nor energy. KDE is a state of the art DE and it works pretty well for me (and has been for many years in gentoo).

I do agree there needs to be more coordination but that’s often hard in a FOSS project since everyone wants to work on what he/she likes and is interested in. I’ve seen a lot of change in gentoo during the last months and I especially enjoy reading blogs of devs like you, Diego.

"Blast from the recent past; two years ago" by Rafek

Thu, 03 Jul 2008 05:32:31 +0000

I’m using Gentoo since 2003 and still fascinated of it. Even if the last times things aren’t going good and I’m thinking about changing the distribution I can’t do it because even if Gentoo isn’t improoving but collapsing somehow – there still is no better distro than Gentoo. Gentoo gainet such incredible advantage on other distros that even if things wont go better next month’s it still be my choice. I’m dreaming of Gentoo back in fit. Even if I have to pay for it, even a lot of money. But non-free distro never get such good like Gentoo is. Only if I magae to get some spare time I’ll try myself on Bugday.

Sorry for my rusty english.

"Again about .la files (or why should they be killed off sooner rather than later)" by thewtex

Thu, 03 Jul 2008 03:32:46 +0000

you may want to look into this http://git.naquadah.org/?p=~arnau/xcb-util.git;a=summary

"Blast from the recent past; two years ago" by Flameeyes

Thu, 03 Jul 2008 01:55:12 +0000

I think none of these is a failed project, and I think they are all actually quite useful.

KDE might be a bit rough lately but it’s still well worked on. Out of kernel drivers are an unfortunate necessity (I dislike them too, but they are needed at the moment), and Gentoo/FreeBSD is a very nice proof of concept and a very well working system too.

I don’t think what Gentoo needs is focus, it’s more like it needs coordination.

"Blast from the recent past; two years ago" by Tester

Thu, 03 Jul 2008 01:29:37 +0000

Well, I think two years ago there were people going in all kinds of directions. I think now we are more focused. We should stop wasting our time with failed projects like KDE, out of kernel drivers or FreeBSD… and focus on useful stuff.

"A few risks I see related to the new portage 2.2 preserve-libs behaviour" by Flameeyes

Wed, 02 Jul 2008 13:07:39 +0000

The full rebuild is done through @preserve-rebuild that is what Portage actually tells you to do after a bump.

What I agree with, though, is that Portage should consider doing the rebuild by itself by default, even if this turns out to be undeterministic.

"A few risks I see related to the new portage 2.2 preserve-libs behaviour" by Mart Raudsepp

Wed, 02 Jul 2008 12:27:10 +0000

@Sebastian: With portage-2.2 you get bugged after every upgrade and some other cases with something like this:

!!! existing preserved libs: >>> package: media-libs/mesa-7.1_rc1 * – /usr/lib64/libGLU.so.1.3 * – /usr/lib64/libGLU.so.1.3.070003 Use emerge @preserved-rebuild to rebuild packages using these libraries

So that’s your facility of informing you.

"A few risks I see related to the new portage 2.2 preserve-libs behaviour" by Sebastian Redl

Wed, 02 Jul 2008 11:24:11 +0000

How am I going to do a full rebuild? Which facility of Portage 2.2 informs me that a library had a soname bump, so that I need to rebuild it? I can no longer rely on revdep-rebuild for that, since the linking isn’t actually broken.

In other words, my immediate reaction will be to do nothing at all. After all, everything still works.

Then come the incremental updates. Portage doesn’t do deep updating by default, so my next emerge -u world will upgrade only packages directly mentioned in the world file, and dependencies if a higher version is required.

This means that it is very likely that programA (after the update) links directly against libraryB.so.2 and indirectly to libraryB.so.1 through libraryC, which wasn’t updated because programA’s new version doesn’t depend on a higher version of libraryC than the old version.

Also, if I must do a full rebuild on upgrading a library, what have I gained? OK, so a package might keep working until the complete rebuild is over, whereas without preserve-libs it will break during the update process. Big deal. The expat debacle was pretty much the only place where that mattered, and this new feature is the wrong solution to the problem.

So basically, I consider this all a mistake. It doesn’t remove the problem (a full rebuild is needed or things will break), it makes the obvious solution harder (revdep-rebuild won’t work anymore), and it makes the problem more subtle (things will break possibly weeks after the update, not immediately).

The expat problem should have been solved by being able to mark a library as build-critical. Libraries marked such force an automatic revdep-rebuild after an soname update, done by portage itself, before continuing merges. Because – since kdeconfig and qtconfig at least, and I think even pkgconfig depend on expat – the upgrade broke all builds anyway, spreading chaos.

"A few risks I see related to the new portage 2.2 preserve-libs behaviour" by Flameeyes

Mon, 30 Jun 2008 21:15:31 +0000

FreeBSD breaks ABI on every mini-change, which creates a HUUUUGE amount of libraries that have compatible interface but incompatible soname. So I wouldn’t count them as a good example, the problems might not happen because the libraries are compatible.

Beside, it’s not a problem of the linker usig the old libraries, but a problem of two libraries being linked in before hand.

Marcus, I hope people do their full rebuild immediately. But I know Murphy.

But yeah I agree it’s a step forward anyway :)

"A few risks I see related to the new portage 2.2 preserve-libs behaviour" by geekounet

Mon, 30 Jun 2008 19:56:44 +0000

A possible thing to do would be to move the preserved libs to a directory apart (which would still be in /etc/ld.so.conf) instead of the standards /lib and /usr/lib, so that we are sure that the linker would never link to it. FreeBSD’s ports does it by moving it to /usr/local/lib/compat/pkg, and it works quite well. (at least I never had a problem with it for now).

"A few risks I see related to the new portage 2.2 preserve-libs behaviour" by Marcus D. Hanwell

Mon, 30 Jun 2008 19:16:09 +0000

Wouldn’t virtually every user perform a full rebuild anyway? At which point the old library is removed and if anything was missed then the problem would be more obvious. I think the new behaviour in portage 2.2 is certainly a step in the right direction where we will hopefully have a lot less breakage resulting in crippled systems. At least we can then rebuild at our leisure instead of the night before giving a talk! It is good to discuss these issues, I am no expert in linking but I consider the new behaviour to be very beneficial.