As in the summary, expat-2.0.0 removes the symbolic link /usr/lib/libexpat.so.0. That breaks a lot of programs (all from kde and some other) I fixed manually with: # ln -sfn /usr/lib/libexpat.so.1 /usr/lib/libexpat.so.0 May be useful to fix in some way the ebuild.
You need to run revdep-rebuild, this is not a bug - the ABI changed. Don't symlink anything, that's wrong.
(In reply to comment #1) > You need to run revdep-rebuild, this is not a bug - the ABI changed. > I not agree. It needs to recompile a lot of software, not only some packets. X server may not start at all and the problem isn't easy to understand for the amministrator. The ebuild doesn't show any advise. I know it's wrong to add a symlink, but I thing it needs some other solution then a simple revdep-rebuild.
Back to dev-libs/expat-1.95.8 Salute
Created attachment 83146 [details] proposed patch with new warning I hope the new warning may helps. Don't expect more from me.
Silently updating a package which requires you to rebuild all of gnome, openoffice, apache, etc... and that stops you from opening a simple gnome-terminal while you haven't rebuilt those packages (not to mention possibly crashing firefox and others already running...), and given that rebuilding all those packages will take *days* in most systems (in mine it certainly does), I understand this should have been handled with more care. of course, ~arch is for nutheads like us who want to get screwed from time to time, but maybe this problem should have been taken up to gentoo management, I expected to see at least an announcement in the GWN about this coming update. at least, i strongly hope to hear some hornets when it gets to 'arch'. best regards, ale
Is it possible to run revdep-rebuild --library libexpat.so.0 -p, then create the symlink to make the system usable and then run revdep-rebuild to link to the new library?
Ok, I'm running ln -sf /usr/lib/libexpat.so.1.5.0 /usr/lib/libexpat.so.0 && revdep-rebuild --library libexpat.so.0 && rm /usr/lib/libexpat.so.0 so the system is usable while rebuild packages to the new expat-2.0.0.
Well I can't even do the revdep-rebuild because of missing libexpat.so.0 I've now donwgraded expat to be able to go to this site. Giacomo, will that work? Newbie me wonders if that won't make the programs still to be linked to the missing library??
I think that updating a package that makes you rebuild the whole system just because there is a new version (THAT NO APP STILL USES) its a bit odd. I think that gentoo should choose more wisely the developers. Not everyone has 30GHZ machines to be rebuilding the whole system. In the last few days there have been like a lot of packages that arent even tested, even a few days ago dvdbackup was commited to the portage, and the guy that commited the ebuild didnt even had time to see that it didnt work? Well.. I think that something that requires building a lot of big packages should be a little more ... tought before commiting. These are my 20 cents...
(In reply to comment #8) > Well I can't even do the revdep-rebuild because of missing libexpat.so.0 Interesting.I'm in the middle of a revdep-rebuild that will hopefully fix this problem (and in regards to "crashing firefox and others already running..." in comment #5 I'm submitting this using Firefox on the same system) it apparently causes varying degrees of lost system functionality. Unfortunatly, KDE is in the rebuild list.
Isn't it possible to handle this upgrade the same way as a openssl upgrade? if [[ -e ${ROOT}/usr/lib/libcrypto.so.0.9.6 ]] ; then ewarn "You must re-compile all packages that are linked against" ewarn "OpenSSL 0.9.6 by using revdep-rebuild from gentoolkit:" ewarn "# revdep-rebuild --library libssl.so.0.9.6" ewarn "# revdep-rebuild --library libcrypto.so.0.9.6" ewarn "After this, you can delete /usr/lib/libssl.so.0.9.6 and /usr/lib/libcrypto.so.0.9.6" touch -c "${ROOT}"/usr/lib/lib{crypto,ssl}.so.0.9.6 fi It's not the nicest way but will prevent some serious problems. Packages affected on my systems so far are, KDE, Gnome, GTK2, apache.
There should not be any update that brokes completely the system!! 44 packages in my system!! This is not serious. What is happening in gentoo the last weeks? I hope non well tested packages in ~arch but no entirely system breakage!!!
149 packages, to safe rebuild them (without any link named libexpat.so.0) I did: perl-cleaner all (I also updated perl) emerge -1 XML-Parser emerge -1 hal (this make sure I can reboot fine) revdep-rebuild --library libexpat.so.0 I had an issue emerging kradio, revdep-rebuild stopped, so I did: emerge --unmerge kradio revdep-rebuild --ignore --library libexpat.so.0 (ignore is to ignore previous results and recalculate list of packages, otherwise it restart emerging all mine 149 packages...)
I found also that revdep-rebuild doesn't accept svn ebuilds asking permission for svn site certificate. (kopete-svn , in my case). An "emerge -1 kopete-svn" let me accept certificate and fixed, another revdep-rebuild --ignore --libraby /ur/lib/libexpat.so.0 will be needed.
(In reply to comment #11) > Isn't it possible to handle this upgrade the same way as a openssl > upgrade? Yes, please! Or else can expat please be SLOT-ted so we can have both 1.95.8 and 2.0.0 installed at the same time? See also bug 128108, bug 128065, and bug 128085 for some of the other trouble this upgrade has caused. Fortunately, I was still able to immediately downgrade to 1.95.8 before something bad happened. I am glad my system didn't crash (sometimes happens to me because I'm running Windows/coLinux), because I would have had trouble even logging in to fix things as so many programs were broken (xterm, Firefox, svn, etc.)!
(In reply to comment #15) > (In reply to comment #11) > > Isn't it possible to handle this upgrade the same way as a openssl > > upgrade? > > Yes, please! Or else can expat please be SLOT-ted so we can have both > 1.95.8 and 2.0.0 installed at the same time? No, we've already discussed this for quite some time. It's not safe. You will end up with applications linked against both expat versions, being really broken and much harder to diagnose the real issue. expat ebuilds not advises users to run revdep-rebuild, therefore this bug is FIXED. No point in more moaning here really, there's simply no better *and* safe way to handle this, sorry. There are separate bugs about revdep-rebuild, hence this discussion is off-topic here.
So I made the link as suggested in Giacomo's comment #7: ln -sf /usr/lib/libexpat.so.1.5.0 /usr/lib/libexpat.so.0 && revdep-rebuild --library libexpat.so.0 This put kde in a state in which it would run, thank you! Runing revdep-rebuild reports that the oofice binarys are broken and reinstalls them. Running revdep-rebuild after this results in the same error messages about open orifice and nothing else is rebuilt. Did the symlink just get removed and need to be relinked? Is my system gonna start flaking out any minute?
Open Office (and most other binary applications) will always fail revdep-rebuild. If those are all you see then they are running just as well as ever, revdeb-rebuild just can't find the files they're pointing to because they were installed differently.
I run in this problem again today. So i did a recompile of most of the software, for example my urxvt (rxvt-unicode), with expat-2.0.0 installed, but it does not only link against expat-2, urxvt also links agains expat-1! HAL2000 ~ # ldd /usr/bin/urxvt linux-gate.so.1 => (0xffffe000) libXft.so.2 => /usr/lib/libXft.so.2 (0xb7fbf000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7ed4000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7e6a000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7e62000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7e34000) libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb7e27000) libperl.so.1 => /usr/lib/libperl.so.1 (0xb7d27000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7d14000) libnsl.so.1 => /lib/libnsl.so.1 (0xb7cff000) libdl.so.2 => /lib/libdl.so.2 (0xb7cfb000) libm.so.6 => /lib/libm.so.6 (0xb7cd6000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7ca9000) libutil.so.1 => /lib/libutil.so.1 (0xb7ca5000) libc.so.6 => /lib/libc.so.6 (0xb7b8c000) /lib/ld-linux.so.2 (0xb7fe7000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/libgcc_s.so.1 (0xb7b82000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7b77000) libexpat.so.0 => not found libXau.so.6 => /usr/lib/libXau.so.6 (0xb7b73000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7b6e000) libz.so.1 => /lib/libz.so.1 (0xb7b5d000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7b3f000)
I was able to take the following steps to get KDE working, it should probably work for your software as well. I'm doing this from work so I don't have the exact commands at my fingertips. I've since also done a 'perl-cleaner all' as someone else had mentioned... emerge -C expat (If you have expat v1 on your system still) revdep-rebuild world (wait for it to fail, if it doesn't fail the following steps aren't necessary) rev /root/.revdep-rebuild.5(whatever the file was... I know this isn't quite correct) | cut -b4- | cut -d- -f2 | rev | sort -u > /root/revdep-packages nano -w /root/revdep-packages -- Manually fix any broken things that are left, you may have to re-iterate the next step a time or two to catch them all... emerge -C $(</root/revdep-packages) emerge $(</root/revdep-packages) emerge --new-flags -Du world I'm still haven't seen the results of the last command yet... it's waiting at home. This MAY work as an abriviated procedure. emerge -c expat (If you have expat v1 on your system still) revdep-rebuild world (wait for it to fail, if it doesn't fail the following steps aren't necessary) rev /root/.revdep-rebuild.5(whatever the file was... I know this isn't quite correct) | cut -b4- | cut -d- -f2 | rev | sort -u > /root/revdep-packages nano -w /root/revdep-packages -- Manually fix any broken things that are left, you may have to re-iterate the next step a time or two to catch them all... emerge (options for Empty and Oneshot?) $(</root/revdep-packages) emerge --new-flags -Du world
