Bug 290781 – Avoid loops with @preserved-rebuild

• Product: Portage Development
• Status: RESOLVED DUPLICATE

[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 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 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 2012-06-24 20:34:06 UTC]

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