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 290781 - Avoid loops with @preserved-rebuild
Summary: Avoid loops with @preserved-rebuild
Status: RESOLVED DUPLICATE of bug 364425
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: preserve-libs
  Show dependency tree
 
Reported: 2009-10-27 17:26 UTC by Martin von Gagern
Modified: 2012-06-24 20:34 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 Martin von Gagern 2009-10-27 17:26:51 UTC
I just happened to run "emerge @preserved-rebuild" three times in a row before I got suspicious that something wasn't right here.

The cause of my actual problem was bug #290726 related to USE=x264:
media-video/ffmpeg-0.5_p20373 depends on >=media-libs/x264-0.0.20091021 but
media-video/avidemux-2.5.1-r2 depends on <media-libs/x264-0.0.20090908

Each time I ran @preserved-rebuild, one of these packages was in the set, and got emerged along with its dependency, the corresponding version of x264. This lead to an upgrade or downgrade of that package, which preserved the installed version and added the other package to the set.

It would be nice if portage could spot such issues. I'm not sure how. If the information about which packages the preserved libs originally belonged to is present somewhere, then from a user interface perspecitve it would be desirable if an "emerge @preserved-rebuild" could spot if such a package would be merged again.

I imagine an error message like this:

media-video/ffmpeg-0.5_p20373 is in the @preserved-rebuild set due to its use of /usr/lib/libx264.so.78 which originally belonged to media-libs/x264-0.0.20091021. However the build will re-install that package, making the rebuild of ffmpeg-0.5_p20373 superfluous. Emerge will abort now. Either emerge media-libs/x264-0.0.20091021 manually or configure media-video/ffmpeg-0.5_p20373 so that it doesn't depend on media-libs/x264-0.0.20091021 any more.

Yes, this is a bit verbose, and difficult to adapt to multiple packages, but that's the kinf of information I'd expect ebuild to convey to users. The key point is that emerging both x264 and ffmpeg doesn't make sense for @preserved-rebuild, as emerging the former provides just the library we have preserved. Therefore the admin is required to fix the issue manually.

I don't know how well this could be integrated in the portage design, how well such additional checks can be integrated with the way sets are implemented. I understand if you tell me this is not possible, but the wish remains.
Comment 1 Zac Medico gentoo-dev 2009-10-27 19:27:37 UTC
You can use the --complete-graph option to check for upgrade/downgrade issues like this. It's not enabled by default because it makes small dependency calculations significantly slower.
Comment 2 Zac Medico gentoo-dev 2011-04-22 03:54:00 UTC
(In reply to comment #1)
> You can use the --complete-graph option to check for upgrade/downgrade issues
> like this. It's not enabled by default because it makes small dependency
> calculations significantly slower.

Since portage-2.1.9.42 and portage-2.2.0_alpha26, downgrades automatically trigger --complete-graph mode:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f90df89f9053bdad96d61935d704f33239f3fed5

However, it won't help if your conflicting packages (ffmpeg and avidemux) are not both pulled in as dependencies of the world set. It seems like this was probably the case, since otherwise you probably would have noticed a "slot conflict" error at some point. Anyway, I plan to implement a --preserved-rebuild target (bug #364425) which will solve this problem by automatically excluding any packages that are eligible for removal by --depclean.
Comment 3 Zac Medico gentoo-dev 2012-06-24 20:34:06 UTC

*** This bug has been marked as a duplicate of bug 364425 ***