I did a rather nasty rebuild after frying my system with kde4 svn.Anyway after purging all kde stuff and rebuilding about everything with an 'upgrade' to ~amd64 the expat problem showed up and no - revdep-rebuild didn't fix it because gtk+ still was complaining about missing libexpat.so.0
Finally got everything to run (seems like anyway) by emerging a older version of expat and then emerging expat2 to slot 2 like somebody mentioned in the bugreport.
Nice thing the maintainers point out that there is the revdep message with new expat version but unfortunately that doesn't seem to work for a bunch of people.
Just telling people to shove it if they run unstable is also not really a resolution to stuff like that - heck,the first post in this thread is close to a year old and this still isn't fixed?Plus the bugstatus reads resolved. This is openssl ,gnome2 and the likes all over again.

I just switched to ~amd64 and I'm having this problem too. Maybe there should be some sort of warning before you emerge the new expat to notify us that we have to re-emerge or revdep-rebuild everything. I was thinking that they could put something like this into portage when emerging it:

Code:

WARNING: Upgrading expat requires that you do a revdep-rebuild or many packages will be broken, do you want to continue? [yes/No]

Something like this should be implemented BEFORE it gets emerged, not after, but I don't know if portage is able to do something like this...

So i emerge expat-2.0 and i noticed that certain programs wouldn't launch anymore. then i revdep-rebuild, and at first it looks like it's going to fix it, but it fails when trying to build a package that requires the expat library. i remerged neon like users suggested earlier in the thread before running revdep-rebuild and still, nothing.

As a temporary solution I just blocked all versions greater than or equal to 2.0. Does anybody know if theres a definite solution to this (besides revdep-rebuild which does NOT work)?_________________website

This expat-2.0.0 just hit me when upgrading to a fcron fix. Revdep-rebuild wanted to install some packages that portage balked out. Anyway, my fix was to go back stable to the problem fcron with deps. That remerged expat and all the others back to previous 'working' status, since didn't know what the problem was at first. Then did a --oneshot for the new fcron fix.

Not touching this new unstable expat until have to._________________Support bacteria – they’re the only culture some people have.”

Today I upgraded to the stable gnome-2.18 and metacity wasn't compiling complaining about XML, then I checked XML-Parser and expat and found that expat was unmasked, I don't know if they fixed their numbering issues but metacity compiled fine after I manually masked it. So maybe it's better left masked until we make sure that nothing will break with it, after all it is a dependency of many packages._________________Regards,
Dritan

It doesn't seem like the original problem was ever fully solved here. I ran revdep-rebuild, and everything worked correctly except SVN. I noticed that when trying to use layman. The problem is that apr-util is slotted, and slot 0 must be rebuilt also. I donno if the newest version of revdep-rebuild accounts for the slot

I think there will be a lot of this kind of threads in the coming week. It's not the devs' fault, though.

@dritan: New versions of expat break compatibility with previous ones. That's why it was kept in unstable for as long as possible. Now that new versions of gnome and kde have been marked stable, it was a suitable time to release expat as well.

After upgrading expat and curl, do a revdep-rebuild to see which packages need to be re-emerged. I had about 25 packages to do._________________Gnome:
1. A legendary being.
2. A never ending quest to make unix friendly to people who don't want unix and excruciating for those that do.

Sorry, my bad. I had been using gnome-experimental until about a month ago and went back to stable, so now that 2.18 is stable I didn't go through the guide, I will do the revdep-rebuild as soon as I get home._________________Regards,
Dritan

I couldn't wait to get home so I sshed from office and while revdep-rebuilding gtk2 won't compile, it complains about pango and when I tried re-emerging pango it wanted libexpat.so.0, should I unmask pango-1.16.5?_________________Regards,
Dritan

I tried to run an 'emerge -uvDa world' over the weekend and got about halfway through the 300+ packages only to hit a problem when attempting to rebuild Metacity. So I looked at the error, poked around the forum here and found out about the problem with expat. I've been through every possible iteration of revdep-rebuild and just unmerging and re-installing expat. No luck. Here's the output of my latest revdep-rebuild attempt:

!!! compile failed
!!! If you need support, post the topmost build error, and the call stack if relevant.
!!! A complete build log is located at '/var/tmp/portage/x11-libs/gtk+-2.10.14/temp/build.log'.

revdep-rebuild failed to emerge all packages
you have the following choices:

- if emerge failed during the build, fix the problems and re-run revdep-rebuild
or
- use -X or --package-names as first argument (trys to rebuild package, not exact
ebuild)
or
- set ACCEPT_KEYWORDS="~<your platform>" and/or /etc/portage/package.unmask
(and remove /root/.revdep-rebuild.5_order to be evaluated again)
or
- modify the above emerge command and run it manually
or
- compile or unmerge unsatisfied packages manually, remove temporary files and
try again (you can edit package/ebuild list first)

To remove temporary files, please run:
rm /root/.revdep-rebuild*.?_*

I've also tried 'revdep-rebuild -X --library libexpat.so.0' which attempts to build fewer packages to no avail. It seems that every time the system hits gtk+, it freaks out. I've also tried unmerging gtk+ but now that it's not on the system, trying to re-install it still hits this same problem. Should I just put a symlink in called libexpat.so.0? I've done things like that in the past no matter how unwise it is, just to get things going. But, it seems this is a larger problem and I'd really like to fix it the "right" way. Any ideas? For the time being my laptop is screwed until I can get past this snag. Would it be better for me to mask any version of expat higher than 2.x and revdep-rebuild again?

maybe next time start by reading the guide and you´ll know what breaks.

That's just silly.

GWN has been broken for a while -- if there was something announced in there I would have seen it. And there is nothing at gentoo.org, so even if I did check online every time I did an emerge -uvD world I wouldn't have known about the guide until I started getting errors.

But even then, the guide is pitifully inadequate -- gnome-pilot and epiphany no longer build and there is no mention of gettext/XML-Parser/subversion breakage. Having >5 gentoo systems I sysadmin (including AMD64, Pentium -4 and -M, so no emerge -k for me), fixing this breakage now feels old hat.

The best strategy for minimal system downtime seems to be something along the lines of the following:

the emerge -uvD world before the revdep-rebuild will cause some things to get compiled/installed twice, but revdep-rebuild bails too easily -- it really should try much harder to fix as much of your system as possible without intervention. Doing `emerge -uvD --newuse world` and `emerge --depclean` will optimise your chances of it finding all the packages.

I haven't an answer to this posted yet, but here is the problem I am having with this:

I have been compiling various dependencies manually with emerge --oneshot [package] to try to get KDE 3.5.7 to compile after this libexpat nonsense (since revdep-rebuild isn't able to build packages in the right order, apparently). However, I've hit a brick wall with kdemultimedia. I want to build it with xine support, but whenever the config step of the compile tries to execute the Xine binary, it fails because Xine is linked to the old version of libexpat. I've tried recompiling the package xine-ui twice, to no avail. Checking dynamic linking on the xine binary still shows: