| View previous topic :: View next topic |
| Author |
Message |
GWilliam
Guru
Joined: 29 Dec 2005
Posts: 350
|
 Posted: Sat Aug 11, 2007 5:15 pm Post subject: #null |
 |
|
#NULL
Last edited by GWilliam on Sun Jul 25, 2010 4:19 am; edited 5 times in total |
|
| Back to top |
|
 |
GWilliam
Guru
Joined: 29 Dec 2005
Posts: 350
|
| Posted: Sat Aug 11, 2007 5:23 pm Post subject: |
|
|
#NULL
Last edited by GWilliam on Sun Jul 25, 2010 4:20 am; edited 1 time in total |
|
| Back to top |
|
|
nixnut
Bodhisattva
Joined: 09 Apr 2004
Posts: 10974
Location: the dutch mountains
|
| Posted: Sat Aug 11, 2007 5:44 pm Post subject: |
|
|
a newer version of expat was stabled, and it is incompatible with the previous version, so you'll need to run revdep-rebuild -X. Run revdep-rebuild -p afterwards to check if anything else needs to be rebuild. In the Portage and Programming forum you'll find a number of threads about the expat update problem.
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered
talk is cheap. supply exceeds demand |
|
| Back to top |
|
|
GWilliam
Guru
Joined: 29 Dec 2005
Posts: 350
|
| Posted: Sat Aug 11, 2007 6:47 pm Post subject: |
|
|
#NULL
Last edited by GWilliam on Sun Jul 25, 2010 4:20 am; edited 1 time in total |
|
| Back to top |
|
|
Carlo
Developer
Joined: 12 Aug 2002
Posts: 3356
|
| Posted: Sat Aug 11, 2007 9:03 pm Post subject: |
|
|
| GWilliam wrote: | | However, was creating that symbolic link a bad idea? |
Symlinking libraries instead rebuilding against the new ones is always a very bad idea.
_________________
Please make sure that you have searched for an answer to a question after reading all the relevant docs. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23584
|
| Posted: Sat Aug 11, 2007 9:27 pm Post subject: |
|
|
GWilliam: libexpat.so.* are part of dev-libs/expat. As nixnut said, a new version was marked stable. I suspect Portage upgraded it without you noticing. If so, you did have a libexpat.so.0 before the upgrade, which is why your programs were functional. Run emerge -pv dev-libs/expat to see what version you have installed.
If you want to blame anybody in this, blame the upstream author who decided to change the ABI and not support parallel installation of the old and new releases. Based on Gnome-2.18, KDE.3.5.7 and expat-2.0.0 - stable soon, it looks like the Gentoo maintainers have done their best to minimize the trouble caused by this upgrade. I think that if they could have made it smoother (for example, by using slots), they would have. |
|
| Back to top |
|
|
jonnevers
Veteran
Joined: 02 Jan 2003
Posts: 1594
Location: Gentoo64 land
|
| Posted: Sun Aug 12, 2007 12:02 am Post subject: |
|
|
| Hu wrote: | | I think that if they could have made it smoother (for example, by using slots), they would have. |
I had to mask >=expat-2 to get anything going again.
using expat > 2.0, created a situation exactly like the OP that I seem unable to emerge/revdep-rebuild my way out of. I'm not a novice to portage and certainly not to softare development and I am stumped as to how to get out.
saying "all you need to do is run revdep-rebuild and revdep-rebuild -X" doesn't help people in the situation i am because revdep-rebuild's package list never emerge's correctly. I removed kdelibs, kamera, digikam, gamma, and a couple other packages JUST to get emerge to make a depgrah. and it never gets through emerge any kdelibs (ARCH or ~ARCH on amd64) with expat > 2.0.
So I'm masking it. There seems to be no other option then to mask expat and get my emerged packages back to a stable state and updated to current... then try unmasking it again...
OP: try | Code: | | echo ">=dev-libs/expat-2" >> /etc/portage/package.mask |
|
|
| Back to top |
|
|
ojbyer
n00b
Joined: 07 Sep 2005
Posts: 41
|
| Posted: Sun Aug 12, 2007 3:15 pm Post subject: Re: How can I solve all these upgrade problems? |
|
|
| GWilliam wrote: | | Obviously Portage/emerge/ebuild scripts can't be trusted for this, revdep-rebuild isn't a simple solution, everything I've read in these forums has just pointed me in more dead-end directions, and hell--I'm sick of this shit, I'm tired, and I'm stumped. |
Often when revdep-rebuild won't work, emerge -e will work. I had this problem on a machine that I use as a mythtv server, and running "emerge -e mythtv" worked out all the qt/kdelibs problems, then I could use "revdep-rebuild" to catch all the remaining packages.
As a last resort, "emerge -e world" should fix anything, as long as your toolchain isn't broken. |
|
| Back to top |
|
|
cobralgato
Apprentice
Joined: 14 Sep 2005
Posts: 228
|
| Posted: Sun Aug 12, 2007 5:52 pm Post subject: |
|
|
revdep-rebuild -X --library libexpat.so.0 worked for me..
_________________
x86_64 |
|
| Back to top |
|
|
a7thson
Apprentice
Joined: 08 Apr 2006
Posts: 176
Location: your pineal gland
|
| Posted: Sun Aug 12, 2007 7:33 pm Post subject: |
|
|
| cobralgato wrote: | | revdep-rebuild -X --library libexpat.so.0 worked for me.. |
You must be luckier than I - following the provided instructions broke my system at gtk+ after perhaps 20 packages had been successfully re-emerged by revdep-rebuild, at which point any gtk-dependent application was now broken thanks to a missing/incompatible libexpat. (libexpat -> gettext) and (libexpat -> XML-Parser) look to be the source of all the breakage, also fun is (libexpat -> python with "build" USE flag). Luckily I was able to restore the key pieces from binary packages, mask libexpat, and re-emerge everything that revdep-rebuild had broken. Were I running ~amd64 on any/all of the key packages it would be my own fault  but I'm not and generally assume a "stable" upgrade is exactly that... and usually, it's a good assumption to make.
_________________
i7-3610QM | E5-2670 | FX-8300 |
|
| Back to top |
|
|
GWilliam
Guru
Joined: 29 Dec 2005
Posts: 350
|
| Posted: Sun Aug 12, 2007 9:32 pm Post subject: |
|
|
#NULL
Last edited by GWilliam on Sun Jul 25, 2010 4:20 am; edited 1 time in total |
|
| Back to top |
|
|
GWilliam
Guru
Joined: 29 Dec 2005
Posts: 350
|
| Posted: Sun Aug 12, 2007 10:18 pm Post subject: |
|
|
#NULL
Last edited by GWilliam on Sun Jul 25, 2010 4:20 am; edited 1 time in total |
|
| Back to top |
|
|
GWilliam
Guru
Joined: 29 Dec 2005
Posts: 350
|
| Posted: Sun Aug 12, 2007 10:23 pm Post subject: |
|
|
#NULL
Last edited by GWilliam on Sun Jul 25, 2010 4:21 am; edited 1 time in total |
|
| Back to top |
|
|
96140
Retired Dev
Joined: 23 Jan 2005
Posts: 1324
|
| Posted: Sun Aug 12, 2007 10:28 pm Post subject: |
|
|
--
Last edited by 96140 on Fri Sep 13, 2013 9:10 am; edited 1 time in total |
|
| Back to top |
|
|
ojbyer
n00b
Joined: 07 Sep 2005
Posts: 41
|
| Posted: Sun Aug 12, 2007 10:34 pm Post subject: |
|
|
| GWilliam wrote: | | What do I do now? |
I really recommend you unmask expat, then try "emerge -e world". As far as I know, this is the only way to make sure all the packages get built in the correct order.
I had the a very similar problem: when I upgraded to kde-3.5.7, the kopete package kept failing. I ignored this for about a week (--resume --skip-first), then this expat problem hit.
revdep-rebuild couldn't generate a good dependency graph, since my (old) version of kopete wanted a different version of kdelibs than everything else. revdep-rebuild isn't always smart enough to know that the solution is to just upgrade kopete at the same time.
If you do an --emptytree merge, then all of these issues get sorted out. You might as well upgrade expat at the same time so you get past this issue. |
|
| Back to top |
|
|
jonnevers
Veteran
Joined: 02 Jan 2003
Posts: 1594
Location: Gentoo64 land
|
| Posted: Sun Aug 12, 2007 10:39 pm Post subject: |
|
|
| if you have the xeffects overlay in your PORTDIR_OVERLAY variable you might want to disable it and then bring your system up to portage current. xeffects has the side effect of a kdelibs-3.5.7-r2 that is ~ARCH while portage's is ARCH, maybe other incompatibilities. |
|
| Back to top |
|
|
a7thson
Apprentice
Joined: 08 Apr 2006
Posts: 176
Location: your pineal gland
|
| Posted: Sun Aug 12, 2007 10:49 pm Post subject: |
|
|
In rebuilding GTK+, I got to a configure error "Can't link to pango. Pango is required to build GTK+." (etc); attempting to rebuild pango failed. attempting to rebuild cairo (upon which pango and gtk+ depend) failed. I re-emerged the earlier (stable ) version of expat, and if memory serves, then emerged cairo, then pango, then gtk+, then did revdep-rebuild -X, and remember doing a few more emerges based on "equery depends expat" output, including re-emerging gettext. Apologies for the lack of detail, I was quite frustrated by this point and up through early hours of the morning, just trying to "make it work again" :-S
| GWilliam wrote: | Oh--I should have included this--this is just before the make errors:
| Code: | | [lots of compiler output, blah, blah, blah, blah]... > gtk.immodules var/tmp/portage/x11-libs/gtk+-2.10.13/work/gtk+-2.10.13/gtk/.libs/lt-gtk-query-immodules-2.0: error while loading shared libraries: libexpat.so.1: cannot open shared object file: No such file o r directory |
revdep-rebuild cannot re-emerge /x11-libs/gtk+-2.10.13 because it's looking for libexpat.so.1, which I don't have.
My brain is now broken.
Can anybody tell me how to fix all this? |
_________________
i7-3610QM | E5-2670 | FX-8300 |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23584
|
| Posted: Mon Aug 13, 2007 1:30 am Post subject: |
|
|
| GWilliam wrote: | | Quote: | | Symlinking libraries instead rebuilding against the new ones is always a very bad idea. |
Interesting, considering that--and I just discovered this--libexpat.so.0 is supposed to be a symlink to the actual object! (In this case, it's supposed to be a link to libexpat.so.1.5.2.) |
In the case you cite, libexpat.so.0 is used as an alternate name for libexpat.so.0.5.0, which is acceptable since they are created by the same package and programs linking to either one expect the same ABI. Carlo was responding to your comment where you created a symlink from libexpat.so.0 to libexpat.so.1.5.2. While it may work in this case, arbitrarily symlinking one name to another is not correct, since there is no guarantee that the two have compatible ABIs. At best, incompatible programs will fail to start with an undefined symbol error. You might get unlucky and get the program to start, but crash or suffer memory corruption due to the mismatched ABI.
| GWilliam wrote: | | Quote: | | If you want to blame anybody in this, blame the upstream author who decided to change the ABI and not support parallel installation of the old and new releases. |
First, I'm not particularly interested in finger pointing. I've re-read my original post and not found anything that seemed particularly accusatory. However, now that you mention it, why the heck would I blame upstream development? |
You sounded irate and tired. Some people in that state want a target for the their frustration. As I said, upstream changed the ABI for expat and did not support keeping programs built against the old release functional while you upgrade to a newer release. That is why you might blame them. It is good that you are not interested in assigning blame.
| GWilliam wrote: | | Upstream does not control this distribution, what gets included, how packages are managed--why blame them? There are always going to be upstream changes that break compatibility. However, the group that distributes this code in the form of an operating system chooses what code they integrate into their distribution and how that code is integrated into their distribution. Also, the package management system is supposed to be able to manage installing, upgrading, and removing packages. That's what it's for. The package management system should NOT break the system in the course of its normal operation. Although I can certainly understand how this could have slipped right through unit testing, I cannot believe that issues caused by expat library incompatibility would not have been caught in basic system testing. If the new Expat package is reasonably expected to break a system, why unmask it, unleashing it on unsuspecting users? Why couldn't the ebuild script have done a much, MUCH better job--or at the very least, displayed a message with nixnuts' revdep-rebuild mantra? |
Technically, the package management system did not break your system. It removed files from the previous version, but did not remove arbitrary files owned by other packages. I will grant that, depending on system configuration, removing dev-libs/expat could cripple a system to the point that the system may as well be considered broken. In general, I consider anything you can recover without a LiveCD not to be broken.
According to /usr/portage/dev-libs/expat/ChangeLog, expat-2.0.0.ebuild was added to Portage on 24 Mar 2006, more than a year ago. Six days later, such a warning was added to the ebuild: | Code: | ewarn "Please note that the soname of the library changed!"
ewarn "If you are upgrading from a previous version you need"
ewarn "to fix dynamic linking inconsistencies by executing:"
ewarn "revdep-rebuild -X --library libexpat.so.0"
|
| GWilliam wrote: | | As for the parallel installation of the expat libraries, I'm not at all qualified to debate the matter, but even though a slotted approach might have made the upgrade a lot smoother, why would upstream development assume that anyone would want to keep two versions of this library? Again, I really don't know enough about the matter to even have an opinion about it, but it seems to me as if one would simply (were it possible) upgrade from one to the other. |
Long term, there would not be a need to keep both. However, if both versions could be kept safely on the system temporarily, then you would be able to upgrade the packages at leisure, with any non-upgraded versions binding to the old library, and newly built programs binding to the new Expat v2.0 libraries. |
|
| Back to top |
|
|
leifbk
Guru
Joined: 05 Jan 2004
Posts: 425
Location: Bærum, Norway
|
| Posted: Mon Aug 13, 2007 6:37 am Post subject: |
|
|
| Hu wrote: | Technically, the package management system did not break your system. It removed files from the previous version, but did not remove arbitrary files owned by other packages. I will grant that, depending on system configuration, removing dev-libs/expat could cripple a system to the point that the system may as well be considered broken. In general, I consider anything you can recover without a LiveCD not to be broken.
According to /usr/portage/dev-libs/expat/ChangeLog, expat-2.0.0.ebuild was added to Portage on 24 Mar 2006, more than a year ago. Six days later, such a warning was added to the ebuild: | Code: | ewarn "Please note that the soname of the library changed!"
ewarn "If you are upgrading from a previous version you need"
ewarn "to fix dynamic linking inconsistencies by executing:"
ewarn "revdep-rebuild -X --library libexpat.so.0"
|
|
I think that it would be great if Portage just halted after emerging packages requiring a revdep-rebuild. That would give us a chance to actually read what to do before proceeding 
_________________
Grumpy old man |
|
| Back to top |
|
|
mope
Apprentice
Joined: 23 Feb 2003
Posts: 206
|
| Posted: Mon Aug 13, 2007 9:47 am Post subject: |
|
|
| leifbk wrote: | | Hu wrote: | Technically, the package management system did not break your system. It removed files from the previous version, but did not remove arbitrary files owned by other packages. I will grant that, depending on system configuration, removing dev-libs/expat could cripple a system to the point that the system may as well be considered broken. In general, I consider anything you can recover without a LiveCD not to be broken.
According to /usr/portage/dev-libs/expat/ChangeLog, expat-2.0.0.ebuild was added to Portage on 24 Mar 2006, more than a year ago. Six days later, such a warning was added to the ebuild: | Code: | ewarn "Please note that the soname of the library changed!"
ewarn "If you are upgrading from a previous version you need"
ewarn "to fix dynamic linking inconsistencies by executing:"
ewarn "revdep-rebuild -X --library libexpat.so.0"
|
|
I think that it would be great if Portage just halted after emerging packages requiring a revdep-rebuild. That would give us a chance to actually read what to do before proceeding |
I think the idea is to read changelogs before proceeding, rather than upgrading for upgrading's sake
that's what my buddy does anyway... |
|
| Back to top |
|
|
leifbk
Guru
Joined: 05 Jan 2004
Posts: 425
Location: Bærum, Norway
|
| Posted: Mon Aug 13, 2007 10:50 am Post subject: |
|
|
| mope wrote: | | leifbk wrote: | | I think that it would be great if Portage just halted after emerging packages requiring a revdep-rebuild. That would give us a chance to actually read what to do before proceeding |
I think the idea is to read changelogs before proceeding, rather than upgrading for upgrading's sake
that's what my buddy does anyway... |
Sure -- if you ain't got nothing else to do, that sounds great. I'm doing an "emerge --sync && emerge -avuDN world" once or twice a week, and generally things are proceeding just fine. I believe that a lot of people might find an extra option like "--halt-on-dependency-conflicts" quite useful.
_________________
Grumpy old man |
|
| Back to top |
|
|
jonnevers
Veteran
Joined: 02 Jan 2003
Posts: 1594
Location: Gentoo64 land
|
| Posted: Mon Aug 13, 2007 12:21 pm Post subject: |
|
|
| a7thson wrote: | | Code: | | [lots of compiler output, blah, blah, blah, blah]... > gtk.immodules var/tmp/portage/x11-libs/gtk+-2.10.13/work/gtk+-2.10.13/gtk/.libs/lt-gtk-query-immodules-2.0: error while loading shared libraries: libexpat.so.1: cannot open shared object file: No such file o r directory |
|
to correct this you must emerge the following pckages in this order:
| Code: | emerge fontconfig
emerge pango
emerge gtk+
then do the revdep-rebuild -X libexpat.so.1 |
I couldn't recompile pango until fontconfig was recompiled. |
|
| Back to top |
|
|
mope
Apprentice
Joined: 23 Feb 2003
Posts: 206
|
| Posted: Mon Aug 13, 2007 8:20 pm Post subject: |
|
|
| leifbk wrote: | | mope wrote: | | leifbk wrote: | | I think that it would be great if Portage just halted after emerging packages requiring a revdep-rebuild. That would give us a chance to actually read what to do before proceeding |
I think the idea is to read changelogs before proceeding, rather than upgrading for upgrading's sake
that's what my buddy does anyway... |
Sure -- if you ain't got nothing else to do, that sounds great. I'm doing an "emerge --sync && emerge -avuDN world" once or twice a week, and generally things are proceeding just fine. I believe that a lot of people might find an extra option like "--halt-on-dependency-conflicts" quite useful. |
how many updates are you coming across per cycle since you're donig it so often?
I can't imagine you're updating more than 2 packages each time you do that...if you'd sit there and read a halt alert, why wouldn't you read the change log before you emerge the package?
My guess is that people will ignore *both* the changelogs and the warnings, regardless of how large or colorful they're made. |
|
| Back to top |
|
|
GWilliam
Guru
Joined: 29 Dec 2005
Posts: 350
|
| Posted: Mon Aug 13, 2007 11:16 pm Post subject: |
|
|
#NULL
Last edited by GWilliam on Sun Jul 25, 2010 4:22 am; edited 1 time in total |
|
| Back to top |
|
|
GWilliam
Guru
Joined: 29 Dec 2005
Posts: 350
|
| Posted: Mon Aug 13, 2007 11:24 pm Post subject: |
|
|
#NULL
Last edited by GWilliam on Sun Jul 25, 2010 4:22 am; edited 1 time in total |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
