[gentoo-amd64] Re: upgrade clobbered /lib symlink

[Duncan]

Kirk Lowery <empirical.humanist@×××××.com> posted
e74dfca60906040548r3b0c1c89sf73c9f5e47119ede@××××××××××.com, excerpted
below, on  Thu, 04 Jun 2009 08:48:13 -0400:

> I have a dual Opteron box that has successfully run a "nomultilib"
> 64-bit only system for years. For various reasons, the box had not been
> updated for a long time. I did a major upgrade over several days,
> incrementally. Somewhere along the way, some ebuild clobbered my /lib
> symlink to /lib64. My profile is "nomultilib" and my global USE flags
> include "-multilib". I discovered the problem when I tried to restart
> one of my servers, restored the symlink,and everything works fine. Happy
> ending.
>
> My question: I have all the portage logs from the upgrade. Is there some
> way I can determine which ebuild first changed the symlink? I need to
> determine whether there is a bug in that ebuild, or it was simply a
> glitch because of the massive set of upgrades. In the first case, I'd
> like to file a bug on that package. On the other hand, it may not be
> worth the time and effort.
>
> But I'm willing to devote a couple of hours of research to this in the
> community interest.

Very interesting.  FWIW, the lib-lib64 symlink has flipped a time or two 
over the years, depending on what stage tarball the base install came 
from and possibly depending on the baselayout version.  Thus, I'd 
investigate baselayout first.  (Added later:) Also see
http://bugs.gentoo.org/show_bug.cgi?id=132135, and check xorg and glibc 
(bug 122274) as well.

equery belongs (with equery being part of gentoolkit) would be helpful in 
this sort of situation in /most/ cases, but here I'm not so sure, since a 
package is said to "own" a directory if it has any files in it, and 
portage only removes it on uninstall if there's nothing left in it after 
it removes the files the uninstalled package owns, thus saving the dir if 
other packages own it or if there's orphaned or non-package files in the 
dir.  Since we're talking about the major /lib and /lib64 dirs here, a 
larger number of packages than normal are likely to own them.  At least 
it's not /usr/lib and /usr/lib64 we're talking about, as a HUGE number of 
packages will own them!

Still, you /might/ find something if you look for those that use the 
symlink form, since those should be far fewer and the package rather out 
of the ordinary.  At least here, nothing reports the symlink form, and 
baselayout doesn't own either dir but openrc owns /lib64.  However, as 
the openrc clue will indicate to many, I'm using ~amd64 keywords and thus 
baselayout v2 (2.0.1 to be exact), so that's not going to be 
representative of a stable amd64 baselayout v1 installation (which 
doesn't use openrc as it's effectively both packages in one) at all.

But I doubt that'll turn up anything.

Something that /might/ turn up something would be grepping the portage 
logs for references to /lib. Of course, depending on the grep, you may 
get ALL /lib references including the ones in /usr, both the plain lib 
and the lib64 versions, and even /usr/libexec and private lib subdirs 
such as /usr/kde/3.5/lib or whatever, so you may have to play with the 
grep/search a bit to reduce the number of false positives.  For various 
technical reasons, such system-wide changes are often specifically 
scripted, outside the usual portage install uninstall operations, so it's 
possible you can trim the search by throwing in a reference to rm, as 
well.

Meanwhile, I read the dev list and someone happened to mention something 
that sounded very much like what you are saying, a bug due to a removed 
/lib or /lib64 symlink.  My eyes perked up (ears perked up is the usual 
phrase, but I was reading not listening in this case) at that, but it was 
merely a passing reference with basically no additional information, IIRC 
not even a bug number I could look at, so I haven't the foggiest whether 
it's actually related to this or not, nor do I remember now which thread 
or any other context, so finding who it was to mail them and ask would be 
difficult.  It's really rather frustrating.  However, that does indicate 
that there's a good chance they already know about it.  Thus unless 
you're seriously curious (as I imagine I would be, when such things 
happen I want to know why and how, in ordered to determine how likely 
they are to occur again!), you might just decide they've probably caught 
the bug already based on the above, and leave it at that.

Finally, if you're still interested in investigating the matter and given 
that we now know there's likely a bug filed on it, you can try searching 
filed bugs.  In fact, I'm already curious enough about it to do one 
search...

On Gentoo bugzilla I used the search "ALL /lib symlink", and came up with 
the above listed early bugs (at the "added later" note), but nothing as 
recent as I recall that dev list reference being.  So I don't know...

But the other possible method, assuming not /too/ many packages were 
updated and/or that you search against the system-wide packages like 
baselayout, glibc, gcc, xorg-server, etc that are most likely to cause 
the problem, first, and leave say codecs and such unlikely candidates for 
later, would be to do an ALL bugzilla search against each one, checking 
the bugs filed in say the last three months, and see what you come up 
with.

If you figure out what it was, please do post an update, and/or link the 
bug or whatever.  I'm curious, and as I said, as any good admin upon 
seeing an unsolved mystery such as this, wonder at the possibility of it 
hitting here, even if it's reasonably unlikely given that on ~amd64 and 
updating generally a couple times a week, I'm likely long past any danger.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman