| Summary: | lib & lib64 roles are reversed in some pre 2005.0 amd64 installations | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Dietrich Moerman <dietrich.moerman> |
| Component: | New packages | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | blocker | CC: | amd64, asomers, benjamin200, bug.hunter, decamps, eero, gentoo, jakub, jwind-gentoo, krallkrall, lfarkas, m.debruijne, m.malmborn, marcec, mathfox, mattm, mvolaski, pierre, pogosyan, zak.kipling |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | xorg-x11-6.8.2-r7 emerge log | ||
|
Description
Dietrich Moerman
2006-05-03 08:06:41 UTC
What is the symlink that is made? Also, please attach a full emerge log. You can generate one by setting PORT_LOGDIR appropriately. Same problem here. Apparent the offending code is in backward_compat_install
dosym ../${DIR} /usr/X11R6/${DIR}
where DIR happened to be lib64. Since /usr/X11R6 is symlinked to /usr, you have /usr/lib64 symlinked to ../lib64, which is itself.
I can imagine many 64 bit machine people would be pissed, because it's a security update.
(In reply to comment #2) > I can imagine many 64 bit machine people would be pissed, because it's a > security update. Nothing has changed in this section, so they have no right to get pissed about this particular update. The code handling migration has been static for quite a while. I thought the symlink goes to ../usr/lib64. So it creates a never ending circle. I will try to reemerge as soon as I can. Could it be because I'm using Portage 2.1? Created attachment 86197 [details]
xorg-x11-6.8.2-r7 emerge log
This is the full emerge log.
If it may be of interest, this is where Portage halts (not included in log): >>> /var/lib/xdm/.keep --- /var/lib/xkb/ >>> /var/lib/xkb/README Traceback (most recent call last): File "/usr/bin/emerge", line 3413, in ? mydepgraph.merge(pkglist) File "/usr/bin/emerge", line 2026, in merge retval=portage.doebuild(y,"merge",myroot,self.pkgsettings,edebug,tree="porttree") File "/usr/lib/portage/pym/portage.py", line 2887, in doebuild mydbapi=mydbapi, vartree=vartree, prev_mtimes=prev_mtimes) File "/usr/lib/portage/pym/portage.py", line 3070, in merge mydbapi=mydbapi, prev_mtimes=prev_mtimes) File "/usr/lib/portage/pym/portage.py", line 6472, in merge cleanup=cleanup, mydbapi=mydbapi, prev_mtimes=prev_mtimes) File "/usr/lib/portage/pym/portage.py", line 6109, in treewalk self.mergeme(srcroot,destroot,outfile,None,secondhand,cfgfiledict,mymtime) File "/usr/lib/portage/pym/portage.py", line 6272, in mergeme mymtime=movefile(mysrc,mydest,newmtime=thismtime,sstat=mystat, mysettings=self.settings) File "/usr/lib/portage/pym/portage.py", line 2927, in movefile dstat=os.lstat(os.path.dirname(dest)) OSError: [Errno 2] No such file or directory: '/usr/lib64/X11' Downgraded to Portage 2.0.54 and merging xorg-x11 now works. This is a bug in Portage 2.1_pre10-r2. *** Bug 132850 has been marked as a duplicate of this bug. *** Tried emerge xorg-x11 again under portage 2.1_pre10-r5. Failed at the same place. Somehow my system has the lib64 links backwards: lib64 is a symlink to lib instead of lib to lib64. Both in / and /usr. After I fixed the dirs by rm lib64 && mv lib lib64 && ln -s lib64 lib in busybox (bb.) emerge xorg-x11 went successfully. (In reply to comment #9) > Tried emerge xorg-x11 again under portage 2.1_pre10-r5. Failed at the same > place. Somehow my system has the lib64 links backwards: lib64 is a symlink to > lib instead of lib to lib64. Both in / and /usr. > > After I fixed the dirs by rm lib64 && mv lib lib64 && ln -s lib64 lib in > busybox (bb.) emerge xorg-x11 went successfully. > That worked for me. Thanks. How did the links get swithced in the first place though? They didn't get switched, and that's the problem. In 2004.3, /usr/lib64 -> /usr/lib was the convention. That changed with 2005.0. I think either portage needs to do some sanity checking on these links or all ebuilds need to be able to handle both cases. The former seems to be simpler, something like this:
function switchlib64() {
echo "cd $1 && rm lib64 && mv lib lib64 && ln -s lib64 lib" | bb
}
[ -L /lib64 ] && switchlib64 /
[ -L /usr/lib64 ] && switchlib64 /usr
(In reply to comment #12) > I think either portage needs to do some sanity checking on these links or all > ebuilds need to be able to handle both cases. The former seems to be simpler, > something like this: OK, reassigning. I personally dislike the idea of putting that into portage very much. That sort of thing should have been in the 2005.0 upgrade guide. If the AMD64 team wants to support such a fix up, they are more than welcome to add it to bashrc in the profiles and have it run at a time when root is guaranteed... That traceback might be worth fixing though. (In reply to comment #14) > I personally dislike the idea of putting that into portage very much. That sort > of thing should have been in the 2005.0 upgrade guide. If the AMD64 team wants > to support such a fix up, they are more than welcome to add it to bashrc in the > profiles and have it run at a time when root is guaranteed... > > That traceback might be worth fixing though. > It was in the upgrade guide. frankly, 2004.3 has been been removed from the tree for quite some time. We had a period for almost a year where we maintained the upgrade docs. At this point our advice is to reinstall. Sorry for the incorrect claim. The only version I could find was one in blubb's devspace. So, that traceback is all that needs to be worred about? *** Bug 138120 has been marked as a duplicate of this bug. *** *** Bug 138521 has been marked as a duplicate of this bug. *** um - my bug http://bugs.gentoo.org/show_bug.cgi?id=138520 has been marked as a dup of this. I am not using AMD64, i am on a P4 - 32 bit. I am not doing anything with xorg. I am upgrading openldap and unsure whether it's okay to simply symlink the now-missing libldap-2.2.so.7 to the current .so, since in the previous occurance of ldap breaking everything, http://bugs.gentoo.org/show_bug.cgi?id=94458 it was stated that making that symlink would be Very Bad, since there were a number of symbol changes between the two libraries. there isn't a circular symlink in my reported issue; there's no symlink at all! This issue has nothing to do with this bug it's gotten merged into - please tell me what i'm missing? (In reply to comment #19) > um - my bug > http://bugs.gentoo.org/show_bug.cgi?id=138520 > > has been marked as a dup of this. > > I am not using AMD64, i am on a P4 - 32 bit. Eh? Move your openldap problems elsewhere, completely unrelated and also not marked as a dupe of this bug at all. (In reply to comment #6) > If it may be of interest, this is where Portage halts (not included in log): [...] FYI, I see the same behaviour with xorg-x11-6.8.2-r8 and portage-2.1-r1 python is FUBAR now. [Professional opinion about stable packages trashing the package management system redacted] *** Bug 138602 has been marked as a duplicate of this bug. *** (In reply to comment #15) > (In reply to comment #14) > > I personally dislike the idea of putting that into portage very much. That sort > > of thing should have been in the 2005.0 upgrade guide. If the AMD64 team wants > > to support such a fix up, they are more than welcome to add it to bashrc in the > > profiles and have it run at a time when root is guaranteed... > > > > That traceback might be worth fixing though. > > > It was in the upgrade guide. frankly, 2004.3 has been been removed from the > tree for quite some time. We had a period for almost a year where we > maintained the upgrade docs. At this point our advice is to reinstall. If I understand this correctly, I need to do a fresh Gentoo install to avoid any future _stable_ packages breaking my system again? Or can I do the above-mentioned lib64/lib renaming thing (any additional advice?) to avoid any problems in the future? I've consistently upgraded my profile from 2004.3 to 2006.0, but I suppose I must've missed this point of the upgrading guide. Is the amd-specific guide still available (I see no link from <http://www.gentoo-linux.org/doc/en/gentoo-upgrading.xml>)? BTW, see the following forum post for the problems people are encountering: <http://forums.gentoo.org/viewtopic-t-475692.html>. In my opinion, xorg-x11-6.8.2-r8 should never have gone stable for amd64. hopefully this problem is resolved for 7.0-r1, now that it's gone stable. I have reversed the directories as said in comment 9. Everything seems to work now. Reinstalling everything is not an option. *** Bug 139084 has been marked as a duplicate of this bug. *** *** Bug 140795 has been marked as a duplicate of this bug. *** *** Bug 139087 has been marked as a duplicate of this bug. *** *** Bug 144625 has been marked as a duplicate of this bug. *** *** Bug 150186 has been marked as a duplicate of this bug. *** *** Bug 150186 has been marked as a duplicate of this bug. *** I opended Bug 150186 xorg-server-1.0.2-r7 failed on AMD64 but it was mark as a duplicate of this bug. I read the workaround in Comment #9 from vicaya but I don't understand how can fix it, sorry. Could anybody please give me the commands to fix the problem? I tried the following: > cd /usr > rm lib64 > ln -s /usr/lib lib64 ...but it doesn't help. Also, the links "ls -l /usr/include/GL" further on point to /usr/lib32. > ls -l /usr/include/GL > lrwxrwxrwx 1 root root 40 Oct 5 19:00 gl.h -> > //usr/lib32/opengl/xorg-x11/include/gl.h > lrwxrwxrwx 1 root root 43 Oct 5 19:00 glext.h -> > //usr/lib32/opengl/xorg-x11/include/glext.h > lrwxrwxrwx 1 root root 41 Oct 5 19:00 glx.h -> > //usr/lib32/opengl/xorg-x11/include/glx.h > lrwxrwxrwx 1 root root 44 Oct 5 19:00 glxext.h -> > //usr/lib32/opengl/xorg-x11/include/glxext.h Can anybody help? Thanks, Ben I finally got it. Solution posted by vicaya: <After I fixed the dirs by rm lib64 && mv lib lib64 && ln -s lib64 lib in <busybox (bb.) emerge xorg-x11 went successfully. Thanks, Ben *** Bug 152388 has been marked as a duplicate of this bug. *** *** Bug 153378 has been marked as a duplicate of this bug. *** *** Bug 157416 has been marked as a duplicate of this bug. *** *** Bug 157637 has been marked as a duplicate of this bug. *** *** Bug 158506 has been marked as a duplicate of this bug. *** Don't really see anything we could do here. *** Bug 189934 has been marked as a duplicate of this bug. *** |
