View previous topic :: View next topic |
Author |
Message |
prophecy Tux's lil' helper
Joined: 17 Nov 2003 Posts: 97
|
Posted: Wed Apr 05, 2006 1:35 pm Post subject: |
|
|
Gergan,
I ran that script and got a null result. I guess that none of my ebuilds depend on libexpat.so.0.
Justace |
|
Back to top |
|
|
Gergan Penkov Veteran
Joined: 17 Jul 2004 Posts: 1464 Location: das kleinste Kuhdorf Deutschlands :)
|
Posted: Wed Apr 05, 2006 1:56 pm Post subject: |
|
|
One little warning about the script, it relies on portage doing the hard work, and here it works fine, but I do not know from which version upwards the portage creates the NEEDED files in its database.
I use the last portage version ~arch and have recently rebuild my system so the chances are probably bad for this script to work if you have a stable portage version or you haven't updated or rebuilt your system recently - in this case only revdep-rebuild could find the breakage.
This said with this portage feature would be ridiculously easy to write a proper revdep-rebuild, which works faster and better than the current one. _________________ "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 |
|
Back to top |
|
|
pgrdsl Tux's lil' helper
Joined: 29 Aug 2002 Posts: 93 Location: Southampton, UK
|
Posted: Wed Apr 05, 2006 2:30 pm Post subject: |
|
|
Gergan Penkov wrote: | for all of you guys and girs, who have still problems with this and that, a script, which will list the packages, linking to expat.so.0
Code: | ...elided bash script...
|
and it is fast... |
Or, you can do this (which is even faster, and is less typing):
Code: |
find /var/db/pkg -name NEEDED -type f -print0 | xargs -0 grep -l 'expat\.so\.0' | cut -f5,6 -d/
|
It assumes that the structure under /var/db/pkg is "sensible", and I've been lazy by not prefixing everything with a "=" (| sed -e 's/^/=/', if you really want it).
A slightly less safe way (and even faster) is:
Code: |
grep -l 'expat\.so\.0' /var/db/pkg/*/*/NEEDED | cut -f5,6 -d/
|
but you'll probably hit command line limits if you have lots of packages emerged.
And Gergan's warning holds: this only works with packages that have been emerged since you've had a version of portage installed that generates the NEEDED file. _________________ pihl |
|
Back to top |
|
|
spiralvoice Apprentice
Joined: 09 Mar 2004 Posts: 238
|
Posted: Wed Apr 05, 2006 2:30 pm Post subject: |
|
|
Matteo Azzali wrote: | except that kradio doesn't compile anymore, but can be caused by other factors) |
Same here, any clues? |
|
Back to top |
|
|
Gergan Penkov Veteran
Joined: 17 Jul 2004 Posts: 1464 Location: das kleinste Kuhdorf Deutschlands :)
|
Posted: Wed Apr 05, 2006 3:36 pm Post subject: |
|
|
@pgrdsl - thanks for the onliners, seems that I must work more on my bash/tools skills _________________ "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 |
|
Back to top |
|
|
prophecy Tux's lil' helper
Joined: 17 Nov 2003 Posts: 97
|
Posted: Wed Apr 05, 2006 3:44 pm Post subject: |
|
|
I think that this is going the wrong direction. I have found an app that depends on libexpat.so.0 and then recompiled it. It then still depends on libexpat.so.0. In addition it also depends on libexpat.so.1 which I find very strange. I do not have my laptop with me right now so I can not check again. The main point is this. I do not have libexpat.so.0 on my system (anywhere that I can find anyway) and for some reson when I re-emerge packages they still have a dependancy on libexpat.so.0. I do not know where it comes from? And now, I am at a loss for where to look.
Justace
P.S. I have got to get this figured out soon, my school work is starting to suffer. |
|
Back to top |
|
|
spiralvoice Apprentice
Joined: 09 Mar 2004 Posts: 238
|
Posted: Wed Apr 05, 2006 4:43 pm Post subject: |
|
|
prophecy wrote: | P.S. I have got to get this figured out soon, my school work is starting to suffer. |
Thats a thing I really hate about Gentoo, when something is broken it takes ages to fix it... |
|
Back to top |
|
|
pgrdsl Tux's lil' helper
Joined: 29 Aug 2002 Posts: 93 Location: Southampton, UK
|
Posted: Wed Apr 05, 2006 4:54 pm Post subject: |
|
|
spiralvoice wrote: | prophecy wrote: | P.S. I have got to get this figured out soon, my school work is starting to suffer. |
Thats a thing I really hate about Gentoo, when something is broken it takes ages to fix it... |
Well, look at it this way, at least you can fix it
Also, if you stick ~x86 in your KEYWORDS then you have to expect problems like this periodically. If you want a more stable system don't go for "unstable".
(I hate it when people say that, but it is actually true: don't use ~x86 if you need your machine to keep working.)
I can't really help on this specific problem - I did a revdep-rebuild and everything worked fine first time. _________________ pihl |
|
Back to top |
|
|
voidzero Bodhisattva
Joined: 21 Jul 2002 Posts: 265 Location: Grnn
|
Posted: Wed Apr 05, 2006 8:33 pm Post subject: |
|
|
So, what happens when stable users will upgrade to this package, as soon as it's marked stable? Users still need to recompile their packages using for example revdep-rebuild, don't they? Or do they just mark this expat version unstable forever?.. _________________ Diplomacy is the art of letting the other party have things your way.
-- Daniele Vare |
|
Back to top |
|
|
sedorox Apprentice
Joined: 13 Feb 2004 Posts: 206
|
Posted: Wed Apr 05, 2006 9:45 pm Post subject: |
|
|
Gergan Penkov wrote: | sedorox wrote: | Well.. I just found out when I updated expat on one of my systems.. that it seems the ebuild creates the symlinks for itself:
Code: |
# ls /usr/lib/libexpa*
-rw-r--r-- 1 root root 136K Apr 5 00:10 /usr/lib/libexpat.a
-rw-r--r-- 1 root root 793 Apr 5 00:10 /usr/lib/libexpat.la
lrwxrwxrwx 1 root root 17 Apr 5 00:10 /usr/lib/libexpat.so -> libexpat.so.1.5.0
lrwxrwxrwx 1 root root 17 Apr 5 00:10 /usr/lib/libexpat.so.1 -> libexpat.so.1.5.0
-rwxr-xr-x 1 root root 117K Apr 5 00:10 /usr/lib/libexpat.so.1.5.0
|
Should I remove the symlinks and run revdep-rebuild, like I did on one of my other systems? |
these links are absolutely correct and should stay this way.
|
I was just confused, because before, everyone was saying that you shouldn't symlink it.. so I'll just leave it then. |
|
Back to top |
|
|
fastly n00b
Joined: 26 Oct 2005 Posts: 21
|
Posted: Wed Apr 05, 2006 9:51 pm Post subject: |
|
|
IMHO, I refuse to believe the solution to this problem includes symlinking libraries. _________________ Gimmie a V, Gimmie an I, Gimmie an S, Gimmie a T, Gimmie an A. What does it spell? VIRUS! |
|
Back to top |
|
|
sedorox Apprentice
Joined: 13 Feb 2004 Posts: 206
|
Posted: Wed Apr 05, 2006 10:09 pm Post subject: |
|
|
fastly wrote: | IMHO, I refuse to believe the solution to this problem includes symlinking libraries. |
I understand.. I'm just saying.. when I first emerged the update on my laptop... it didn't have the symlinks... now when I did it on my other system.. it had the symlinks.... so I wasn't sure if I should remove them.. and recompile the stuff that needs it... |
|
Back to top |
|
|
Gergan Penkov Veteran
Joined: 17 Jul 2004 Posts: 1464 Location: das kleinste Kuhdorf Deutschlands :)
|
Posted: Wed Apr 05, 2006 10:09 pm Post subject: |
|
|
The solution does not include symlinking, what sedorox shows are just standard versioning symlinks, which should be there, they are created for all libs and you have them.
In fact if they don't exist - this will be bug. _________________ "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 |
|
Back to top |
|
|
Polynomial-C Retired Dev
Joined: 01 Jun 2003 Posts: 1432 Location: Germany
|
Posted: Wed Apr 05, 2006 10:28 pm Post subject: |
|
|
Nice breakage
One of my systems ran so deeply into this hell that I am now running emerge -e world in hope to get rid of all the errors this system now is suffering from. And yes I read the info about running revdep-rebuild at the end of expat merge and did it.
When this package becomes stable this will be a huge p.i.t.a. for all users out there...
This is definitely the biggest breakage I ever had with Gentoo. Even the switch from gcc-3.3.x to gcc-3.4.x was not so bad imho because I knew I had to recompile the whole system and was able to schedule this procedure. With expat I felt like being thrown into cold water all of a sudden. And of course the worst thing was that revdep-rebuild didn't find all binaries and libs that have to be rebuild.
I can only hope that Gentoo will support --as-needed soon. When the information I read in this thread is correct, the amount of packages that need to be recompiled would have been drastically less than without --as-needed. _________________ The manual said "Requires Windows10 or better" so I installed GNU/Linux...
my portage overlay
Need a stage1 tarball? (Unofficial builds) |
|
Back to top |
|
|
Gergan Penkov Veteran
Joined: 17 Jul 2004 Posts: 1464 Location: das kleinste Kuhdorf Deutschlands :)
|
Posted: Wed Apr 05, 2006 10:41 pm Post subject: |
|
|
I've read flameeyes blog, but didn't even noticed that it would a prophecy about pending disaster, for your viewing pleasure,
Quote: | Adding to the rebuild list, today exg bumped expat to version 2.0.0, that has ABI changes and gets a soname change between libexpat.so.0 to libexpat.so.1. Unfortunately expat links against lots of stuff, starting from fontconfig that's linked on by most of KDE and GNOME packages... and in usual conditions libexpat.so.0 ends up in almost all binaries, leading to an almost complete world rebuild...
Luckily for me, by using --as-needed most of the stuff was clear: I had to rebuild neon and subversion, hal, dbus (for one of the support programs, but the main dbus daemon and library were fine), and of course fontconfig, this one I did for first as after rebuilding that my KDE was stable again. Oh of course I had to rebuild the stuff that can't use --as-needed: wxGTK and users of it, like vlc and mkvtoolnix, but that's an unfortunate thing... I should probably try to investigate the problem in bfd and fix it sooner or later.. |
http://planet.gentoo.org/developers/flameeyes/2006/03/25/build_and_rebuild _________________ "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 |
|
Back to top |
|
|
fastly n00b
Joined: 26 Oct 2005 Posts: 21
|
Posted: Wed Apr 05, 2006 11:15 pm Post subject: |
|
|
I take back what i said earlier that revdep-rebuild solved this problem for me - it got gnome working but revdep-rebuild still finds files with libexpat.so.0 dependancies and some of them are failing. For example i'm getting this error when compiling nautilus and gnome control-center:
Quote: | /usr/lib/libcairo.so: undefined reference to `__popcountsi2@GCC_3.4' |
I have a feeling this may still be the lingering aftermath of the GCC upgrade to 3.4. I followed the revdep-rebuild method in the GCC upgrade guide, however this does not guaruntee that all packages and shared libraries are compiled with the new version of GCC and can lead to significant and more frustrating problems as we are encountering now in this thread.
My best piece of advice for now would be to, if possible, get your machine into a usable state and perform recompile system and world using emerge -e. Look at this advice from hielvc, in the emwrap.sh thread i referred to earlier, which suggests the order in which the fully recompile should be performed using the emwrap.sh emerge wrapper, to prevent individual failed comilpilations holding up the entire process.
Keep smiling and don't forget that by discussing this problem and collectively solving it here on the forum you are helping to make Gentoo even better for everyone.
Fast _________________ Gimmie a V, Gimmie an I, Gimmie an S, Gimmie a T, Gimmie an A. What does it spell? VIRUS! |
|
Back to top |
|
|
prophecy Tux's lil' helper
Joined: 17 Nov 2003 Posts: 97
|
Posted: Wed Apr 05, 2006 11:35 pm Post subject: |
|
|
pgrdsl wrote: | spiralvoice wrote: | prophecy wrote: | P.S. I have got to get this figured out soon, my school work is starting to suffer. |
Thats a thing I really hate about Gentoo, when something is broken it takes ages to fix it... |
Well, look at it this way, at least you can fix it
Also, if you stick ~x86 in your KEYWORDS then you have to expect problems like this periodically. If you want a more stable system don't go for "unstable".
(I hate it when people say that, but it is actually true: don't use ~x86 if you need your machine to keep working.)
I can't really help on this specific problem - I did a revdep-rebuild and everything worked fine first time. |
You are absolutley correct. I do expect to have problems every now and then, but this is just crazy. Normally I do not have to fight this hard to get my system sorking again. I am just suprised that (at least for my machine) there is not fix. I am now entertaining the emerge -e world option which... Ohh my god I dont want to do. I have tried peoples scripts and the such, I just can not find out where my system thinks that there is libexpat.so.0. I mean really, how can something link to it if it does not exist. |
|
Back to top |
|
|
prophecy Tux's lil' helper
Joined: 17 Nov 2003 Posts: 97
|
Posted: Thu Apr 06, 2006 12:05 am Post subject: |
|
|
B A M M M! ! ! !
So, it looks as though I have two versions of the apps! For some reson the following exists...
Check out the following ( I know it is long )
Code: |
prophecylaptop lib # ls -l /usr/bin/kmplayer
-rwxr-xr-x 1 root root 4504 Apr 5 18:51 /usr/bin/kmplayer
prophecylaptop lib # ls -l /usr/kde/3.5/bin/kmplayer
-rwxr-xr-x 1 root root 8588 Mar 29 15:57 /usr/kde/3.5/bin/kmplayer
prophecylaptop lib # ls -l /usr/lib/libkdeinit_kmplayer.so
-rwxr-xr-x 1 root root 406388 Apr 5 18:51 /usr/lib/libkdeinit_kmplayer.so
prophecylaptop lib # ls -l /usr/kde/3.5/lib/libkdeinit_kmplayer.so
-rwxr-xr-x 1 root root 479918 Mar 29 15:57 /usr/kde/3.5/lib/libkdeinit_kmplayer.so
prophecylaptop lib # ldd /usr/lib/libkdeinit_kmplayer.so
linux-gate.so.1 => (0xffffe000)
libkmplayercommon.so => /usr/kde/3.5/lib/libkmplayercommon.so (0xb7e44000)
libkmediaplayer.so.0 => /usr/kde/3.5/lib/libkmediaplayer.so.0 (0xb7e38000)
libkparts.so.2 => /usr/kde/3.5/lib/libkparts.so.2 (0xb7df1000)
libkutils.so.1 => /usr/kde/3.5/lib/libkutils.so.1 (0xb7d8c000)
libkio.so.4 => /usr/kde/3.5/lib/libkio.so.4 (0xb7a20000)
libkdeui.so.4 => /usr/kde/3.5/lib/libkdeui.so.4 (0xb772c000)
libkdesu.so.4 => /usr/kde/3.5/lib/libkdesu.so.4 (0xb7713000)
libkwalletclient.so.1 => /usr/kde/3.5/lib/libkwalletclient.so.1 (0xb7701000)
libkdecore.so.4 => /usr/kde/3.5/lib/libkdecore.so.4 (0xb74a8000)
libDCOP.so.4 => /usr/kde/3.5/lib/libDCOP.so.4 (0xb7473000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb743b000)
libutil.so.1 => /lib/libutil.so.1 (0xb7437000)
libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0xb741d000)
libidn.so.11 => /usr/lib/libidn.so.11 (0xb73ed000)
libkdefx.so.4 => /usr/kde/3.5/lib/libkdefx.so.4 (0xb73be000)
libqt-mt.so.3 => /usr/qt/3/lib/libqt-mt.so.3 (0xb6cd1000)
libmng.so.1 => /usr/lib/libmng.so.1 (0xb6c6f000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6c4e000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb6c44000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6c40000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6c36000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6c31000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6c2e000)
libXft.so.2 => /usr/lib/libXft.so.2 (0xb6c19000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6be7000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6b73000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6b52000)
libpng.so.3 => /usr/lib/libpng.so.3 (0xb6b2a000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb6b1b000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb6b12000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb6af8000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb6ae5000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6adc000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb69e1000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb69de000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb69d9000)
libdl.so.2 => /lib/libdl.so.2 (0xb69d4000)
libz.so.1 => /lib/libz.so.1 (0xb69c1000)
libfam.so.0 => /usr/lib/libfam.so.0 (0xb69b7000)
libacl.so.1 => /lib/libacl.so.1 (0xb69b0000)
libattr.so.1 => /lib/libattr.so.1 (0xb69ab000)
libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.0.2/libstdc++.so.6 (0xb68cd000)
libm.so.6 => /lib/libm.so.6 (0xb68a7000)
libc.so.6 => /lib/libc.so.6 (0xb6786000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.0.2/libgcc_s.so.1 (0xb677b000)
libXtst.so.6 => /usr/lib/libXtst.so.6 (0xb6775000)
/lib/ld-linux.so.2 (0x80000000)
prophecylaptop lib # ldd /usr/kde/3.5/lib/libkdeinit_kmplayer.so
linux-gate.so.1 => (0xffffe000)
libkmplayercommon.so => /usr/kde/3.5/lib/libkmplayercommon.so (0xb7de2000)
libXtst.so.6 => /usr/lib/libXtst.so.6 (0xb7ddc000)
libkmediaplayer.so.0 => /usr/kde/3.5/lib/libkmediaplayer.so.0 (0xb7dd0000)
libkparts.so.2 => /usr/kde/3.5/lib/libkparts.so.2 (0xb7d89000)
libkutils.so.1 => /usr/kde/3.5/lib/libkutils.so.1 (0xb7d24000)
libkio.so.4 => /usr/kde/3.5/lib/libkio.so.4 (0xb79b8000)
libkdeui.so.4 => /usr/kde/3.5/lib/libkdeui.so.4 (0xb76c3000)
libkdesu.so.4 => /usr/kde/3.5/lib/libkdesu.so.4 (0xb76ab000)
libkwalletclient.so.1 => /usr/kde/3.5/lib/libkwalletclient.so.1 (0xb7699000)
libkdecore.so.4 => /usr/kde/3.5/lib/libkdecore.so.4 (0xb7440000)
libDCOP.so.4 => /usr/kde/3.5/lib/libDCOP.so.4 (0xb740b000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb73d3000)
libutil.so.1 => /lib/libutil.so.1 (0xb73ce000)
libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0xb73b5000)
libidn.so.11 => /usr/lib/libidn.so.11 (0xb7385000)
libkdefx.so.4 => /usr/kde/3.5/lib/libkdefx.so.4 (0xb7356000)
libqt-mt.so.3 => /usr/qt/3/lib/libqt-mt.so.3 (0xb6c69000)
libmng.so.1 => /usr/lib/libmng.so.1 (0xb6c07000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6be5000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb6bdc000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6bd8000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6bce000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6bc9000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6bc6000)
libXft.so.2 => /usr/lib/libXft.so.2 (0xb6bb0000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6b7f000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6b0b000)
libexpat.so.0 => not found
libpng.so.3 => /usr/lib/libpng.so.3 (0xb6ae3000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb6ad4000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb6aca000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb6ab1000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb6a9e000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6a95000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb699a000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb6997000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6991000)
libdl.so.2 => /lib/libdl.so.2 (0xb698d000)
libz.so.1 => /lib/libz.so.1 (0xb697a000)
libfam.so.0 => /usr/lib/libfam.so.0 (0xb6970000)
libacl.so.1 => /lib/libacl.so.1 (0xb6969000)
libattr.so.1 => /lib/libattr.so.1 (0xb6964000)
libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.0.2/libstdc++.so.6 (0xb6885000)
libm.so.6 => /lib/libm.so.6 (0xb6860000)
libc.so.6 => /lib/libc.so.6 (0xb673f000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.0.2/libgcc_s.so.1 (0xb6734000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6713000)
/lib/ld-linux.so.2 (0x80000000)
|
My /var/db/pkg dir does not have any information about the installation in /usr/kde/3.5 which is older. This is why it never found the dependancy.
This would also explane why the revdep-rebuild does not want to recompile anything. It has done what it can. Now the question to answer is why are there two versions of this on my system. The same thing seems to happen with k3b also. So this is not just centered on kmplayer, I was just using this as an example.
Justace |
|
Back to top |
|
|
Gergan Penkov Veteran
Joined: 17 Jul 2004 Posts: 1464 Location: das kleinste Kuhdorf Deutschlands :)
|
Posted: Thu Apr 06, 2006 12:25 am Post subject: |
|
|
Well this more or less explains your problems, but how the hell, this got left there is also a very insteresting question. _________________ "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 |
|
Back to top |
|
|
Suicidal l33t
Joined: 30 Jul 2003 Posts: 959 Location: /dev/null
|
Posted: Thu Apr 06, 2006 1:35 am Post subject: |
|
|
Using my normal update script I had no issues.
Code: | #!/bin/bash
emerge system
revdep-rebuild
emerge -uD system
revdep-rebuild
emege world
revdep-rebuild
emerge -uD world
revdep-rebuild |
|
|
Back to top |
|
|
prophecy Tux's lil' helper
Joined: 17 Nov 2003 Posts: 97
|
Posted: Thu Apr 06, 2006 1:45 am Post subject: |
|
|
Gergan Penkov wrote: | Well this more or less explains your problems, but how the hell, this got left there is also a very insteresting question. |
Ok, I found it to be quite simple once I figured it out.
I decided a long time ago to run the SVN amarok. This pulled in several apps and installed into /usr/kde/3.5 instead of /usr. So I have apparently had more than one copy of these programs on my system at a time. I have been cleaning out the packages by hand and making sure to use the portage system instead of SVN for everthing but amarok. So that was it. All ig finally getting cleaned up now. |
|
Back to top |
|
|
pgrdsl Tux's lil' helper
Joined: 29 Aug 2002 Posts: 93 Location: Southampton, UK
|
Posted: Thu Apr 06, 2006 9:45 am Post subject: |
|
|
voidzero wrote: | So, what happens when stable users will upgrade to this package, as soon as it's marked stable? Users still need to recompile their packages using for example revdep-rebuild, don't they? Or do they just mark this expat version unstable forever?.. |
Well, hopefully by then all the people who don't need a completely stable system and can cope with breakage like this will have come up with a solution
Isn't that the whole point of packages going in to ~x86 before x86? _________________ pihl |
|
Back to top |
|
|
fastly n00b
Joined: 26 Oct 2005 Posts: 21
|
Posted: Thu Apr 06, 2006 11:44 am Post subject: |
|
|
pgrdsl wrote: | voidzero wrote: | So, what happens when stable users will upgrade to this package, as soon as it's marked stable? Users still need to recompile their packages using for example revdep-rebuild, don't they? Or do they just mark this expat version unstable forever?.. |
Well, hopefully by then all the people who don't need a completely stable system and can cope with breakage like this will have come up with a solution
Isn't that the whole point of packages going in to ~x86 before x86? |
I think pgrdsls point is: although ~x86 users may have found a solution by the time the packages are considered stable, that solution may well be to rebuild everything, in which case will the packages ever be unmasked? _________________ Gimmie a V, Gimmie an I, Gimmie an S, Gimmie a T, Gimmie an A. What does it spell? VIRUS! |
|
Back to top |
|
|
pgrdsl Tux's lil' helper
Joined: 29 Aug 2002 Posts: 93 Location: Southampton, UK
|
Posted: Thu Apr 06, 2006 4:00 pm Post subject: |
|
|
fastly wrote: | I think pgrdsls point is: although ~x86 users may have found a solution by the time the packages are considered stable, that solution may well be to rebuild everything, in which case will the packages ever be unmasked? |
(I think you mean "voidzeros point".)
Well, I suspect the answer is "yes, it will". If nothing else, upstream are unlikely to keep supporting the old version forever.
I can't help wonder if there is a libstdc++-3.3 approach that could be taken here (not that I much like that either).
Random idea from top-of-my-head: release an update for expat 1.x to SLOT it. Stick expat 2 in SLOT 2. Make expat 2 (something)DEPEND on an ebuild of expat 1 that only installs the libexpat.so.0 file. Existing binaries will still be able to find .so.1, new builds will build (and link) against expat 2.
Or is that just dumb?
Edit: Well, according to https://bugs.gentoo.org/show_bug.cgi?id=127470#c16, yes it is _________________ pihl |
|
Back to top |
|
|
Havin_it Veteran
Joined: 17 Jul 2005 Posts: 1247 Location: Edinburgh, UK
|
Posted: Thu Apr 06, 2006 4:37 pm Post subject: |
|
|
Seems to me that there will always be upgrades that *should*, to be certain of avoiding problems, necessitate a full-tree rebuild. The art is in identifying such instances and ensuring everybody knows about them in advance. It's a no-brainer that a major-version upgrade of gcc or glibc comes under thius category, but many of us wouldn't know a thing about expat and its ABI change unless we were reading this thread, in which case we're already screwed. It just came in under the radar this time. |
|
Back to top |
|
|
|