Hmm... okay... In that case, you should remerge kde-base/kdepim-kresources - and every other package that equery b some-file-that-revdep-rebuild-complains-about spits out. But that doesn't explain those

I apologize for my rant and would like to ask a question instead.
Is there some way to avoid this breakage or is it just a matter of time until you have to upgrade to expat-2.0 and therefore also have to rebuilt a big part of your system?

I personally didn't have any problems with upgrading to the latest expat. And I'm not what you'd call a major Linux Guru either. All I had to do was upgrade to expat 2.0.0, remerge fontconfig, remerge XML-Parser and then remerge qt 3.3.6. Then I did a revdep-rebuild -X and everything appears to have worked.

Mind you I have a Celeron D 2.93Ghz with 512MB of RAM, with a Pentium III 450Mhz with 512MB acting as a Distcc host. And yes, it took me all day. But hey, I just watched some videos, talked with friends, stuff like that. Before I knew it, my system was updated and running smoothly with the newest expat.

The three things that took the longest were kdelibs, openoffice and wxGTK. Everything else KDE compiles relatively fast.

Yes, I admit that maybe there's something that could've been done to avoid all this headache. But I don't think it's something to get all bent out of shape about. Hey, when I hosed my system when upgrading to glibc 2.4, I didn't freak out. I just said "Crap, should've noticed that," and reinstalled.

I just ran "ln -s /usr/lib64/libexpat.so.1 /usr/lib64/libexpat.so.0" and everything works now AFAIK, if something breaks because of it I'll just downgrade expat and mask version 2. Its really annoying that I recompiled almost 200 packages to try and fix this and it didn't really help. Oh well, thank god for symlinks

With a KDE-3.5.2 system, I installed 'expat-2.0.0' and ran ' revdep-rebuild --library libexpat.so.0'. This took 20 hours after which the system hung and I had to use the dreaded symlink to get the system up and running.
'revdep-rebuild' now shows numerous broken programs but does not recompile anything._________________Gentoo /amd64/2007.0
AMD Athlon64 X2 4200+
ASUS M2N32-SLI Deluxe

Personally, I used the ln -s to recompile XML-Parser and kdelibs, after which I recompiled Firefox (damn thing broke and crashed after the expat emerge completed). I then deleted the symlink from .0 to .1.5.0 and ran revdep-rebuild, which did not complete. I had to reemerge all of the kde programs using emerge -av --oneshot ... where ... is a list of the major kde programs. Interestingly I figured out the subversion failure because of neon somehow. I think I had neon failing before and screwing subversion up.

It is a big hassle, this guy breaking his ABI, and breaking it from the 1.9x series of release candidates up to 2.0.0. There is some statement on expat.sourceforge.net about backwards compatibility

Quote:

The goal was to solidify and stabilize the implementation of the given API, to add desirable features as long as they fit with the API, and to keep the API backwards compatible if extensions were required.

Seems silly to say that and then screw things up like this. I wonder how many programs were actually screwed up by the change. I have only seen one on this list that breaks after symlinking.

What I'm currently trying to do is re-emerging expat 1.95.8, keeping the libexpat.so.0 and upgrading to 2.0.0 again, so I really have both version of the lib installed, while having the headers from the newer one.

Everything depending on the 1.95.8 release should still work, while newly compiled packages should use the new expat library.

If i update to expat-2, i have to run revdep-rebuild because of the missing library error in same aplications.

Kde packages are one of many afected packges, but during the update of the packages, after udpdate kdelibs, i get the fowling error when emerging any kde aplication:

Code:

configure: error:
you need to install kdelibs first.

If you did install kdelibs, then the Qt version that is picked up by
this configure is not the same version you used to compile kdelibs.
The Qt Plugin installed by kdelibs is *ONLY* loadable if it is the
_same Qt version_, compiled with the _same compiler_ and the same Qt
configuration settings.

i have to downgrade to expat-1.95.8 and run revdep-rebuild to get all the programs rigth.

Any advices?

follow the information it gives you. it's telling you that qt and kdelibs have been compiled with different compilers or compile options. to set it straight, try 'emerge -av qt kdelibs'.

Not necessarily. This message is cropping up erroneously for a few people, apparently for a couple of different reasons. Mine was due to UIC segfaulting - I've since stopped it doing that, but still haven't got a working KDE. More here.

atm, it's completely broken and will break the system even more, if given free reign!

that's quite strange, since I used it 2 days ago and it was working fine..... can this be related with the
pax-utils-0.1.11 restriction on emerge we found in kuroo (emerge was stopping at the output "man:" line)?
If so, downgrade pax-utils to 0.1.10 (put app-misc/pax-utils-0.1.11 in /etc/portage/package.mask)
and anything will work fine.
(pax-utils-0.1.11 seems to block any call to emerge that isn't plain use of emerge command in a shell....)_________________Every day a new distro comes to birth. Every day a distro "eats" another.
If you're born distro, no matter what, start to run.
---- http://www.linuxprinting.org/ ---- http://tuxmobil.org/

atm, it's completely broken and will break the system even more, if given free reign!

Right, which is why you all should use the script I posted on the previous page. Run, emerge --oneshot qt kdelibs, and then run that script to recompile kde. You can take the output from revdep-rebuild and manually emerge those items. It's a whole lot safer. I hope revdep rebuild get's fixed soon.

EDIT: When you recompile KDE stuff whether you use that script or revdep-rebuild, it's best to exit completely out of KDE. I found this out the hard way.

EDIT: When you recompile KDE stuff whether you use that script or revdep-rebuild, it's best to exit completely out of KDE. I found this out the hard way.
And: You can take the output from revdep-rebuild and manually emerge those items. It's a whole lot safer. I hope revdep rebuild get's fixed soon.

I can confirm this due to my expat/kde/revdep-rebuild nightmares on three boxes the last two days.

This expat thing has to be the worst Gentoo problem I've had in two years. How could this possibly have been unmasked?

I just ran "ln -s /usr/lib64/libexpat.so.1 /usr/lib64/libexpat.so.0" and everything works now AFAIK, if something breaks because of it I'll just downgrade expat and mask version 2. Its really annoying that I recompiled almost 200 packages to try and fix this and it didn't really help. Oh well, thank god for symlinks

there's probably a lesson to be leart there. If things go wrong, thake a breath and check it out before doing drastic moves like rebuilding half to system "to see if it works ". There's a fair chance you'll dig an even deeper hole that way.

I got this bullshit message from kde about qt versions, checked the forum, decided I had no real need of the new expat, masked it , rebuild the previous version and got back to business.

It'll stay masked until there's a 2.01 or something.

It seems like the expat devs screwed this one up badly.

Let's hope they fix it.

I certainly dont feel like rebuilding just about all the most heavy packages on my working system only to find maybe in a couple of days other bugs are going to creep out.

revdep-rebuild always makes me nervous anyway , I only ever use it with -p option.

_________________Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86

I just ran "ln -s /usr/lib64/libexpat.so.1 /usr/lib64/libexpat.so.0" and everything works now AFAIK, if something breaks because of it I'll just downgrade expat and mask version 2. Its really annoying that I recompiled almost 200 packages to try and fix this and it didn't really help. Oh well, thank god for symlinks

there's probably a lesson to be leart there. If things go wrong, thake a breath and check it out before doing drastic moves like rebuilding half to system "to see if it works ". There's a fair chance you'll dig an even deeper hole that way.

I got this bullshit message from kde about qt versions, checked the forum, decided I had no real need of the new expat, masked it , rebuild the previous version and got back to business.

It'll stay masked until there's a 2.01 or something.

It seems like the expat devs screwed this one up badly.

Let's hope they fix it.

I certainly dont feel like rebuilding just about all the most heavy packages on my working system only to find maybe in a couple of days other bugs are going to creep out.

revdep-rebuild always makes me nervous anyway , I only ever use it with -p option.

At the end of the ebuild for expat it said to run that and usually following the ebuild directions has saved me some in the past.

Something needs to be done about this otherwise users (or worse, corperations that depend on Gentoo) will have this very big problem and more and more will get it the longer we wait. I suggest that mask it right now before others get burned.

What I'm currently trying to do is re-emerging expat 1.95.8, keeping the libexpat.so.0 and upgrading to 2.0.0 again, so I really have both version of the lib installed, while having the headers from the newer one.

Everything depending on the 1.95.8 release should still work, while newly compiled packages should use the new expat library.

Is this a valid solution for a "soft upgrade"? Any opinions?

In my opinion, this would have been preferable to the approach the devs took, which was basically, "Oh, by the way, your system needs to be rebuilt."

There is a function to this in some of the eclasses keep_old_lib or sth like this.
I'm not sure but this API/ABI-change happened a lot time ago with expat, it simply hits gentoo now._________________"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack

and a few other kde apps fail to run as they can no longer find libexpat.so.0 despite being recompiled after the expat update. Given that a few guys mentioned symlinking I'm wondering why I've been left out in the cold without a libexat in my /usr/lib64 ... *ponders* any help/thoughts appreciated.

[update]screw the above - updatedb is b0rked and fails to add the new packages to my locate app, I do have those files after all. I think I'm going to have to live with the nasty symlink hack to make things work for the time being.

[update 2]ok creating the "libexpat.so.0 -> /usr/lib64/libexpat.so.1.5.0" symlink will do me for now - back up and running.

Last edited by haven on Sat Apr 01, 2006 9:00 pm; edited 1 time in total