Yes, these are 0-day bumps, but this is not the point of this bug. The point is a major warning: libxcb-xlib will be gone with these releases and revdep-rebuild will be only of little help. While on an --as-needed system very few libs will break, libxcb-xlib was injected to a lot of la files and revdep-rebuild didn't detect it. The effect was that I was forced to run `find /usr/lib/ -name '*.la' -exec -i -e 's:/usr/lib/libxcb-xlib.la ::g' \;` to get the things moving, as libtool was failing at linking of any lib, depending even indirectly on libX11.
@Jeroen, this is probably more of a portage/revdep-rebuild issue. What do you think? Thanks
I don't think so. I have no idea what this bug is all about - I was just delivering the mail. Apparently we need to start panicking or avoid xcb. :)
Well, that bug was just about the fact, that while revdep-rebuild did detect the broken la files, 'revdep-rebuild -p' output did not include all of those packages. And and all the la files that still contained /usr/lib/libxcb-xlib.la prevented linking of almost every libX11 dependent (especially indirectly) package.
additionally the sed hack will orphan the *.la files to not be considered belonging to the package they do belong to as far as the package manager is concerned, as checksums and such change. That can cause all kinds of fun in corner cases too, so what is really necessary is fixing of .la files in a portage aware way, me thinks. Then again fix_libtool.sh or whatever gcc has for some similar stuff seems to work fine for its purpose?
Or maybe have an elog message that outputs a nice qfile+sed oneliner for people to use? That or fix revdep-rebuild...
(In reply to comment #5) > Or maybe have an elog message that outputs a nice qfile+sed oneliner for people > to use? To do exactly what breaks VDB records of ownerships as far as portage is concern? ;p How does fix_libtool_files.sh work here? > That or fix revdep-rebuild...
*** Bug 246468 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > To do exactly what breaks VDB records of ownerships as far as portage is > concern? ;p > How does fix_libtool_files.sh work here? It orphans them. See also bug 140019, bug 90744. In short: While it is possible to update mtimesdb and hashes, it wasn't done, because libstdc++.la was removed as of gcc-4.1.1. I propose the same be done here. I don't have the libxcb la files and have experienced no adverse effects. See also the epunt_la_files function sent for review on gentoo-dev ml which I'll commit later today if noone objects. It's time to start considering it a Best Common Practice to be punting la files when there's a .so bump or when revdep-rebuild has to be run anyway.
(In reply to comment #8) > See also the epunt_la_files function sent for > review on gentoo-dev ml which I'll commit later today if noone objects. I don't see that this has had all questions or concerned answered fully, but I'll just raise my objections soon on the thread...
(In reply to comment #4) > additionally the sed hack will orphan the *.la files to not be considered > belonging to the package they do belong to as far as the package manager is > concerned, as checksums and such change. FEATURES="unmerge-orphans" is enabled by default, so the changed *.la files usually will be removed during unmerging.
*** This bug has been marked as a duplicate of bug 158476 ***
