Summary: | app-portage/gentoolkit - revdep-rebuild fails to fix x11-libs/xcb-util-0.2 upgrade borkage | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Daniel Santos <daniel.santos> |
Component: | Tools | Assignee: | Portage Tools Team <tools-portage> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | major | CC: | david.gurvich, jakub, mrecho, oli.huber, x11 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174434 | ||
Attachments: | libxxx.la files with anachronistic lib reference |
Description
Daniel Santos
2007-03-06 05:55:26 UTC
Also, this is the directory that was being made when the failure occurred: /var/tmp/portage/x11-libs/gtk+-2.10.9/work/gtk+-2.10.9/gdk Created attachment 112245 [details]
libxxx.la files with anachronistic lib reference
More Info: I examined the set -x output from libtool better and discovered that the reference to libXCBRenderUtil.la was coming from sourcing /usr/lib64/libpangocairo-1.0.la. I searched for all of the .la files that had this reference and this is the list: /usr/lib64# grep -l libXCBRenderUtil * libbonoboui-2.la libglade-2.0.la libgnomecanvas-2.la libgnomeui-2.la libgtkgl-2.0.la libgtkspell.la libpangocairo-1.0.la libpoppler-glib.la I'm going to unmerge these packages to attempt to solve my problem. None the less, I suspect that this is still a bug. I'm attaching a copy of these files for investigation. Crap, this may be a dupe of #169521, but at least I have more info in this report. As with #169521, revdep-rebuild did not solve the problem. Would the true problem then lie in revdep-rebuild failing to properly resolve this issue (without making a futile attempt to recompile the packages that are broken by the original problem anyway?) Also of note, I tried revdep-rebuild --library "libXCBRenderUtil.*" and this also failed in the exact same way. To solve my problem, I've unmerged everything with this reference (except for gcc and python) and I'm rebuilding them. Yeah, I know this sucks, but nothing we could do about it, sorry. *** This bug has been marked as a duplicate of bug 169521 *** (In reply to comment #6) > Yeah, I know this sucks, but nothing we could do about it, sorry. > > *** This bug has been marked as a duplicate of bug 169521 *** > I'm willing to wager that it can be addressed in revdep-rebuild. *** Bug 169624 has been marked as a duplicate of this bug. *** Recycling this bug. @x11 folks: - the postinstall instructions are wrong, running revdep-rebuild without any options plain fails - plus what's this hardcoded crap in .la files all over the place (noticed in Bug 158476 already)? (In reply to comment #10) > - the postinstall instructions are wrong, running revdep-rebuild without any > options plain fails It fixed the problem for my system, so it doesn't fail for everyone. I'm open for better suggestions. > - plus what's this hardcoded crap in .la files all over the place (noticed in > Bug 158476 already)? Let me know if you find out. It doesn't make much sense to me either. I found a workaround : first re-emerge pango and after run revdep-rebuild. It seems to work, but revdep-rebuild isn't finished. > - plus what's this hardcoded crap in .la files all over the place (noticed in
> Bug 158476 already)?
Forgive my noob-ness, but are the .la files a shortcut mechanism for libtool so
it doesn't have to scrape through the .so files to figure out what their
dependencies are?
It would seem to me that the purpose of revdep-rebuild is to correct dependency
problems that occur after some package is removed (or in the case of xcb,
updated where the names of it's libs changed). So if libtool will enumerate
through the stated dependencies in the .la files and then fail, it would seem
that this problem lies within the territory of revdep-rebuild.
This most immediate solution that comes to mind involves:
* create a lock file (to make sure that only one revdep-rebuild happens at
once)
* trap SIGINT & SIGTERM (any others?)
* making backups of the .la files in the "broken deps" list (perhaps to
the same dir with .la-revdep-<timestamp> appended? )
* remove the broken dependencies from the .la files to prevent libtool
from failing during the build.
* for each package:
* emerge
* upon success, enumerate through all of the .la files in the "broken"
list that belong to this package remove the .la backup. This presumes
that, upon a successful rebuild we now have a good .la file.
Then, if we get SIGINT or SIGTERM, we clean up by replacing the original .la
files with their backup. There should probably be a mechanism for
revdep-rebuild to look for backup files that were left by a previous run that
was somehow killed more violently (and replace those .la files).
This is just an off-the-top-of-my-head and I don't know the script at all.
Daniel
(In reply to comment #12) > I found a workaround : first re-emerge pango and after run revdep-rebuild. It > seems to work, but revdep-rebuild isn't finished. This may work in your particular instance, but dependency problems can manifest in several different ways. Personally, I had to unmerge all of the packages I could, but I still had broken deps in gcc and python. So I manually removed the broken references from those .la files so that I was able to do all of my rebuilds without libtool failing. (In reply to comment #13) > > - plus what's this hardcoded crap in .la files all over the place (noticed in > > Bug 158476 already)? > > Forgive my noob-ness, but are the .la files a shortcut mechanism for libtool so > it doesn't have to scrape through the .so files to figure out what their > dependencies are? As noted on Bug 158476 Comment #3, this shouldn't end up scattered across loads of .la files (see Comment #2 in this bug), should be just in one place where it belongs... (Honestly this xcb thing is still too much unstable for my taste, I guess people should avoid it until it's more mature and doesn't change all the time.) *** Bug 169521 has been marked as a duplicate of this bug. *** revdep-rebuild in gentoolkit-0.2.4_pre1 should provide better ordering and prevent this issue from occuring. Per comment #17 please test =app-portage/gentoolkit-0.2.4_rc3. Also, is this bug really specific to AMD64? |