In the first emerge session after upgrading to portage-2.2-rc1, I upgraded to ffmpeg-0.4.9_p20080326, resulting in the following notice: !!! existing preserved libs: >>> package: media-video/ffmpeg-0.4.9_p20080326 * - /usr/lib64/libavformat.so.51 * - /usr/lib64/libavformat.so.51.12.1 Use emerge @preserved-rebuild to rebuild packages using these libraries However, the suggested emerge (-p) @preserved-rebuild results in: WARNING: repository at /p is missing a repo_name entry WARNING: repository at /p/layman/sunrise is missing a repo_name entry Error during set creation: Redefinition of set 'world' (sections: 'usersets', 'world') emerge: 'preserved-rebuild' is an empty set emerge: no targets left after set expansion The repository unnamed warnings are bug #228595 (due to symlinks), so that's explained. The error during set creation I've not the foggiest about. (It can be dealt with here or tell me to file another bug, I don't care which.) But why is @preserved-rebuild an empty set, and what am I supposed to do to track and ultimately remove the either current or eventual stale libraries? This may or may not be related to bug #215242 (b), the preserve-libs libgweather issue. There's not enough info there for me to tell. The last comment, some two months ago, says the feature is being rethought to some degree, and presumably /something/ occurred between then and rc1, but there's no hint of what it might have been, if anything, except that the feature still exists in some form in rc1. FWIW: ls /usr/lib64/libavformat.* /usr/lib64/libavformat.a /usr/lib64/libavformat.so.51@ /usr/lib64/libavformat.so.52@ /usr/lib64/libavformat.so@ /usr/lib64/libavformat.so.51.12.1* /usr/lib64/libavformat.so.52.12.0* equery b -f libavformat\.so\.5.* [ Searching for file(s) libavformat.so.5.* in *... ] media-video/ffmpeg-0.4.9_p20080326 (/usr/lib64/libavformat.so.51 -> libavformat.so.51.12.1) media-video/ffmpeg-0.4.9_p20080326 (/usr/lib64/libavformat.so.52 -> libavformat.so.52.12.0) media-video/ffmpeg-0.4.9_p20080326 (/usr/lib64/libavformat.so.51.12.1) media-video/ffmpeg-0.4.9_p20080326 (/usr/lib64/libavformat.so.52.12.0) I guess that means the new ffmpeg package is tracking the old libraries too. Does that mean I have to remerge it to (properly) get rid of them? Shouldn't the above set remerge whatever and then either remerge ffmpeg or remove the old libs from its listing directly? /var/lib/portage/preserved_libs_registry is 6 bytes, "(dp1<lf>.". Is it supposed to be a human-readable list of such libraries? If so, the bug is somewhere in its creation, presumably while merging ffmpeg. I've been sitting on this a couple days with the konsole windows still open on one of my virtual desktops as I was too tired to make any sense of it. I had hoped there'd be a new portage revision available to merge today, to fix it, or at least a bug report, but apparently, anybody else getting it hasn't made enough sense out of it to file a decent bug report either. I'm not sure if I'd call this a "decent" bug report, but it's what I got. It'd be nice if there was at least a bit more documentation on what these new features actually /do/ and how they are supposed to work, at least something a bit more detailed than what's in the release notes. One might expect that by the time it reaches stable-track ~arch and I /did/ check release notes, etc, even on the portage project page. But if it's there, I've not found it, and I looked. At least here, I could use a bit more documentation on both sets and preserve-libs, as I understand the ideas, but really don't even have the foggiest about what sort of files to attach to a bug report. I just happened on the preserved_libs_registry file by pure chance, and thought it looked appropriate, so I included it. Let me know if emerge --info or other files are needed. I'm running ~amd64, the 2007/no-multilib profile. Duncan
I remerged ffmpeg, which as I suspected it should, killed the old versions, did a proper revdep-rebuild (-p, then remerged -1 the listed items manually), rebuilt the two packages that came up, and for now, set FEATURES=-preserve-libs. It might be worth the trouble when it actually works and/or there's more documentation about /how/ it's supposed to work so I can better cleanup after it when it breaks.
(In reply to comment #0) > Error during set creation: Redefinition of set 'world' (sections: 'usersets', > 'world') > The error during set creation I've not the foggiest about. (It can be dealt > with here or tell me to file another bug, I don't care which.) That problem was due to the existence of /etc/portage/sets/world, a symlink to /var/lib/portage/world, as either setup or suggested for an earlier portage upgrade some time ago. Suggestion: Have the portage-2.2 ebuilds test for such a link and delete it if they find it. Duncan
(In reply to comment #0) > The error during set creation I've not the foggiest about. (It can be dealt > with here or tell me to file another bug, I don't care which.) You probably have a symlink /etc/portage/sets/world -> /var/lib/portage/world, just remove the symlink. > But why is @preserved-rebuild an empty set, and what am I supposed to do to > track and ultimately remove the either current or eventual stale libraries? It's probably some kind of race condition that prevents the libraries from being removed correctly, or maybe an isue with stale caches. IOW, you shouldn't have seen the message in the first place. > This may or may not be related to bug #215242 (b), the preserve-libs > libgweather issue. There's not enough info there for me to tell. The last > comment, some two months ago, says the feature is being rethought to some > degree, and presumably /something/ occurred between then and rc1, but there's > no hint of what it might have been, if anything, except that the feature still > exists in some form in rc1. For users nothing has changed, I've just rewritten the backend from scratch. > /var/lib/portage/preserved_libs_registry is 6 bytes, "(dp1<lf>.". Is it > supposed to be a human-readable list of such libraries? If so, the bug is > somewhere in its creation, presumably while merging ffmpeg. No, it's not a human-readable file. > It'd be nice if there was at least a bit more documentation on what these new > features actually /do/ and how they are supposed to work, at least something a > bit more detailed than what's in the release notes. One might expect that by > the time it reaches stable-track ~arch and I /did/ check release notes, etc, > even on the portage project page. But if it's there, I've not found it, and I > looked. At least here, I could use a bit more documentation on both sets and > preserve-libs, as I understand the ideas, but really don't even have the > foggiest about what sort of files to attach to a bug report. I just happened > on the preserved_libs_registry file by pure chance, and thought it looked > appropriate, so I included it. Well, the really interesting information isn't directly stored in any file. As for documentation, as you might know coders often suck at writing user-centric documentation, esp. for stuff they're very familiar with. But I hope to get some docs online over time (when rc2 is released in the next days it will contain a more detailed upgrade doc with a high level description of the new features). > I'm running ~amd64, the 2007/no-multilib profile. Good, that might make it a bit easier to reproduce the problem here.
does it still happen ? we are now at r33 ... if no, please close.
(In reply to comment #4) > does it still happen ? we are now at r33 ... if no, please close. To be truthful I honestly don't know. I've decided that /for/ /me/ it's a misfeature, the benefits are not worth the risks (what happens when someone's cracked due to a lib they thought they'd removed), and FEATURES=-preserve-libs, plus the old routine of revdep-rebuild and emerge depclean after every update, continues to work well enough, here. That means close it. I guess resolved/TESTREQUEST is most accurate...
