Bugzilla Bug 84441

As xorg-x11-6.8.0-r5 was marked stable i tried to update, but got some message
complaining about "cannot write to /usr/lib/X11/locale/lib"
It tells I should use "ebuild
/usr/portage/x11-base/xorg-x11/xorg-x11-6.8.0-r5.ebuild merge" what results in
the same message.
When I checked for the path, I found it is a symlink to
/emul/linux/x86/usr/lib/X11/locale/lib but that path did not exist.

"mkdir /emul/linux/x86/usr/lib/X11/locale/lib" solved the problem

Reproducible: Always
Steps to Reproduce:
1.emerge --sync
2.emerge -u world

Actual Results:  
the merge of xorg-x11 failed, after trying to shutdown the X Server there was
only left a black screen!
Even after reboot the screen went immidiately dark as xdm was started at boot.
I switched to tty1 and typed all things to stop xdm being started at boot time
without seeing what I typed.. not a very comfortable solution ;-)

Expected Results:  
update successfully

I was running:
gnome
thunderbird
firefox
xchat
some terminals

hope I didn't miss something

Sounds like a problem in the emul-xlibs.

*** Bug 82007 has been marked as a duplicate of this bug. ***

What version of emul-linux-x86-xlibs are you using? Can you try remerging it
please - try version app-emulation/emul-linux-x86-xlibs-1.2-r6. This directory
is created and populated.

Actually I was already using emul-linux-x86-xlibs-1.2-r6, because I tried to
get wine working (which is still not compiling, but after I emerged that
version of emul-xlib at least the -lXext problem was gone)

I see in the output of remerging it:
--- /emul/linux/x86/usr/lib/X11/locale/
>>> /emul/linux/x86/usr/lib/X11/locale/lib/
>>> /emul/linux/x86/usr/lib/X11/locale/lib/common/
>>> /emul/linux/x86/usr/lib/X11/locale/lib/common/xlibi18n.so.2 -> ../../../../xlibi18n.so.2
>>> /emul/linux/x86/usr/lib/X11/locale/lib/common/xlocale.so.2 -> ../../../../xlocale.so.2
>>> /emul/linux/x86/usr/lib/X11/locale/lib/common/ximcp.so.2 -> ../../../../ximcp.so.2
>>> /emul/linux/x86/usr/lib/X11/locale/lib/common/xlcUTF8Load.so.2 -> ../../../../xlcUTF8Load.so.2
>>> /emul/linux/x86/usr/lib/X11/locale/lib/common/xlcDef.so.2 -> ../../../../xlcDef.so.2
>>> /emul/linux/x86/usr/lib/X11/locale/lib/common/xomGeneric.so.2 -> ../../../../xomGeneric.so.2
--- /emul/linux/x86/usr/lib/X11/locale/C/
>>> /emul/linux/x86/usr/lib/X11/locale/C/XI18N_OBJS
>>> /emul/linux/x86/usr/lib/X11/locale/C/XLC_LOCALE

this lot of "../"-directory-upwards in front of the path in doubt is somewhat
confusing.

And actually the directory "/emul/linux/x86/usr/lib/X11/locale/lib" does NOT
exist after this remerge.

Should I try switching back to app-emulation/emul-linux-x86-xlibs-1.2-r3?

I played around a bit with the emul-xlib ebuild, here's what I found out:

at the end of the ebuild we find:
pkg_postrm() {
	# The symlink should be removed too.
	if [ -h /usr/$(get_libdir)/X11/locale/lib ]; then
		rm -f /usr/$(get_libdir)/X11/locale/lib
	fi
}

I changed the ebuild to find out what $(get_libdir) is, and it actually is just "lib". (I just added ewarn "/usr/$(get_libdir)/X11/locale/lib was removed" to the if block)

Well, searched for that file, and obviously it is there:
/usr/lib/X11/locale/lib -> /emul/linux/x86/usr/lib/X11/locale/lib

What now strikes ist, that it is there although it should have been deleted while processing that if block.
So "rm -f /usr/$(get_libdir)/X11/locale/lib" does not delete the symlink itself, but the symlink it points to.


Well, back to the problem mentioned above:
"cannot write to /usr/lib/X11/locale/lib"
why does it TRY to write there if it should have been deleted?

This is what I think is the relevant part in xorg-x11-6.8.0-r5.ebuild:
# on amd64 we need /usr/lib64/X11/locale/lib to be a symlink
# created by the emul lib ebuild in order for adobe acrobat, staroffice,
# and a few other apps to work.
if [ -z "${MULTILIB_ABIS}" ]; then
	use amd64 && get_libdir_override lib64
	# lib32 isnt a supported configuration (yet?)
	[ "$(get_libdir)" == "lib32" ] && get_libdir_override lib
fi

So, if I understand what it does, it checks for /usr/lib/X11/locale/lib being a symlink.
As I explained above, this symlink exists, so it tries to write to that symlink, what fails because the thing it pointed to does no longer exist.


So, as far as I see, there are three possible solutions:
1) remove pkg_postrm() from emul-linux-x86-xlibs-1.3-r6.ebuild

2) modify that line in pkg_postrm() to remove the correct thing (I don't know how to do)

3) modify the xorg ebuild(s) to check for that link pointing to something that exists, and if not fix the situation


Most likely 1) would be the easiest one, but I don't understand what deleting the symlink is good for anyways...

I went with option 2, the logic now checks for the link being a symlink and
that the directory it points to does not exist. It was intended to remove a
stray symlink no removal of the package, but also did this on upgrade. Should
be fixed in emul-linux-x86-xlibs-1.2-r7 if you would like to test it.

With regard to the libs etc not being put in place this could be a problem with
your file hierarchy under /emul. If the new ebuild still doesn't work please
attach the output of 'ls -lR /emul/linux/x86/' to this bug and reopen it.

Created an attachment (id=53059) [details]
ls -lR /emul/linux/x86/ > ls-output

I'm sorry, but it is still the same. I didn't try to upgrade to
x11-base/xorg-x11-6.8.2-r1, because it will most likely fail without
/emul/linux/x86/usr/lib/X11/locale/lib existing.

I tried the new ebuild both with and without that directory existing when the
merge is started, it results in deleting the directory anyways.

It looks to me like X11 -> ../X11R6/lib/X11 is your problem, as this is not
used and should not be there. Try deleting it - 'rm
/emul/linux/x86/usr/lib/X11', and then emerge the -r7 release again. It will
still delete the symlink if it points to nothing. If that works then I could
add a bit of extra logic into the ebuild to check for this erronous symlink and
remove it. I have not seen this particular problem on any other systems though.

Yes, you're right. Now it did work!

I don't know how this symlink came there, I recently updated from -r3 to -r6, and afterwards it must have been there, probably it was already there before.

It is the first time I have seen that link, but I will put an extra check into
the ebuild just in case anyone else is suffering from the same issue. Glad we
got to the bottom of this issue - marking as FIXED.

*** Bug 84773 has been marked as a duplicate of this bug. ***