Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 229695 - sys-apps/portage-2.2_rc1 preserve-libs, media-video/ffmeg upgrade, libformat.so.51
Summary: sys-apps/portage-2.2_rc1 preserve-libs, media-video/ffmeg upgrade, libformat....
Status: RESOLVED TEST-REQUEST
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: preserve-libs
  Show dependency tree
 
Reported: 2008-06-27 09:07 UTC by Duncan
Modified: 2009-07-04 17:53 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Duncan 2008-06-27 09:07:52 UTC
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
Comment 1 Duncan 2008-06-27 10:30:37 UTC
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.
Comment 2 Duncan 2008-06-27 11:07:19 UTC
(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
Comment 3 Marius Mauch (RETIRED) gentoo-dev 2008-06-27 11:18:57 UTC
(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.
Comment 4 DEMAINE Benoît-Pierre, aka DoubleHP 2009-07-04 16:31:39 UTC
does it still happen ? we are now at r33 ... if no, please close.
Comment 5 Duncan 2009-07-04 17:53:31 UTC
(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...