| Summary: | "emerge --update --deep world" keeps wanting to upgrade and then downgrade packages | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Douglas Pollock <douglas.pollock> |
| Component: | Unclassified | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | CC: | A-Mann, andre.hinrichs, avuton, belgix_oz, betelgeuse, christoph.gysin, dertobi123, douglas.pollock, ecd, g1gsw, gentoo-bugs, gentoo-bugs, gentoo-bugs, gentoobugs, greg_g, grossk, henrik, iyosifov, jbc28, jnagyjr, lafou, mholzer, netbox253, phoenixreads, radek, reg, rl, sascha-gentoo-bugzilla, squee, tyler, zeroth |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 33440 | ||
| Bug Blocks: | |||
| Attachments: |
World File for the Affected System
Make Configuration output of emerge --info of the Evandro system |
||
|
Description
Douglas Pollock
2003-01-10 06:31:44 UTC
Created attachment 7161 [details]
World File for the Affected System
Created attachment 7504 [details]
Make Configuration
I don't know whether you've changed anything in portage or not, but I've stopped seeing this behaviour. Hi, same problem here for a few days: root@frodo:/root> emerge -up --deep world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild UD] media-video/avifile-0.7.15.20020816-r1 [0.7.32.20030219] After doing a emerge -u --deep world and compiling/merging of media-video/avifile-0.7.15.20020816-r1: root@frodo:/root> emerge -up --deep world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] media-video/avifile-0.7.32.20030219 [0.7.15.20020816-r1] So, it's caught in a loop. Can I supply any additional data/information. World file, Cache-files, etc?? avifile causes from transcode DEPEND=" avi? ( <=media-video/avifile-0.7.22 >=media-video/avifile-0.7.4 )" What version of xine-lib is supposed to exist? It wants to UD my xine-lib again. Am I supposed to have 0.9.13 or the 1.0_beta? It is a horrible waste of my CPU time to keep switching back and forth. *** Bug 24134 has been marked as a duplicate of this bug. *** *** Bug 24205 has been marked as a duplicate of this bug. *** Same problem (was one of the duplicate reports of this bug) and here's some output for avifile problems I'm getting:
# qpkg -q avifile
media-video/avifile-0.7.32.20030219 *
DEPENDED ON BY:
media-video/drip-0.8.2_pre1
media-video/avifile-0.7.15.20020816-r1
DEPENDED ON BY:
media-video/drip-0.8.2_pre1
media-video/avifile-0.7.32.20030219
DEPENDED ON BY:
media-video/drip-0.8.2_pre1
media-video/avifile-0.7.34.20030319
DEPENDED ON BY:
media-video/drip-0.8.2_pre1
media-video/avifile-0.7.37.20030522
DEPENDED ON BY:
media-video/drip-0.8.2_pre1
media-video/avifile-0.7.37.20030522-r1
DEPENDED ON BY:
media-video/drip-0.8.2_pre1
From the ebuild file:
RDEPEND="gnome-base/gnome-libs
<media-video/avifile-0.7.22
>=media-video/avifile-0.7.4.20020426-r2
Drip is the only thing I have that depends on avifile. This means it really shouldn't be upgrading/downgrading packages like that...right?
Oh, and libmpeg2 has a problem as well for me, drip depends on it. From drip ebuild:
RDEPEND=
...
=media-libs/libmpeg2-0.2.1*
# qpkg -q libmpeg2
media-libs/libmpeg2-0.3.1 *
DEPENDED ON BY:
media-libs/gst-plugins-0.6.1
media-video/drip-0.8.2_pre1
media-libs/libmpeg2-0.2.1
DEPENDED ON BY:
media-libs/gst-plugins-0.6.1
media-video/drip-0.8.2_pre1
media-libs/libmpeg2-0.3.1
DEPENDED ON BY:
media-libs/gst-plugins-0.6.1
media-video/drip-0.8.2_pre1
media-libs/libmpeg2-0.3.2_pre20030625
DEPENDED ON BY:
media-libs/gst-plugins-0.6.1
media-video/drip-0.8.2_pre1
gst-plgugins ebuild:
RDEPEND=
...
mpeg? ( =media-libs/libmpeg2-0.3.1* )
The = in both drip and gst-plugins causes the problem there. Anyway, I could just remove drip, but I'd rather not...
*** Bug 24505 has been marked as a duplicate of this bug. *** *** Bug 24515 has been marked as a duplicate of this bug. *** i have the same problem with vim-core - forum thread is here: http://forums.gentoo.org/viewtopic.php?p=414084 <workaround> i found that CTRL-C during the countdown for the unmerge step is a dirty workaround for the problem. when both versions are emerged it works as it should. perhaps this also works with injecting (didnt test though)... </workaround> see #16240, netbpm upgrades, downgrades, upgrades, etc. after entering emerge -upD world emerge wants to upgrade netbpm and then downgrade netpbm. Info with #16240 I don't have transcode installed portage version: 2.0.48-r7 I have the same behaviour with KDE! It might be an workaround to "--inject" the old version which portage wants to downgrade. I'm seeing the same behavior, portage wants to downgrade a package (qt-3.2.2-r1) that is marked as stable (x86): emerge -uUpvD world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild UD] x11-libs/qt-3.1.2-r4 [3.2.2-r1] +cups -nas -postgres +opengl -mysql -odbc +gif -debug I now have this behavior with libgcrypt. 'emerge -Dup world' upgrades libgcrypt to version 1.1.94 but dependencies of several packages (opencdk and newpg) say it must stay on version 1.1.12 which is perfectly ok since 1.1.94 breaks everything causing several packages to fail compiling. So next time running 'emerge -Dup world' he downgrades again to version 1.1.12. This is an infinitive loop... I did some investigation of the ebuilds and found that none of the installed packages requires a newer version than 1.1.12. So why does emerge want to upgrade? Since the ebuilds and their dependencies seem to be correct I assume it is a bug in the portage tools. Andre, I'd be curious if you have libgcrypt in your world file... Of course, it's not in my world file. The dependency loop is caused by the newpg package. But after all I think portage tools should take care of this and throw an dependency error, shouldn't they? Off topic: I've given up now and deleted newpg to get rid of this dependency loop since it is also declared 'dead' by the GNU people. Now looking for an alternative, since encryption in KMail is currently not working. Will try to rebuild world now to see what happens. *** Bug 66402 has been marked as a duplicate of this bug. *** *** Bug 66403 has been marked as a duplicate of this bug. *** *** Bug 68757 has been marked as a duplicate of this bug. *** My system is doing this with gst-plugins. I've got gnome 2.8 in ~arch installed. -puD tries to downgrade it, -pu upgrades. I can post whatever data you guys would find useful; let me know. The root cause of the problem is known but the fix is quite complex. I highly doubt that the fix will make it into the 2.0.51 line at all. It will be in the subsequent version, however. *** Bug 72568 has been marked as a duplicate of this bug. *** *** Bug 57011 has been marked as a duplicate of this bug. *** *** Bug 42974 has been marked as a duplicate of this bug. *** I'm having the same problema with xorg-x11. It keeps upgrading and downgrading between 6.7.0-r3 and 6.8.0-r4. It is in my world file. It's not fun waiting around an hour every time :) I'll to attach my --info output here too. -------- bagual root # emerge --update --deep world --pretend These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild UD] x11-base/xorg-x11-6.7.0-r3 [6.8.0-r4] -------- Created attachment 49844 [details]
output of emerge --info of the Evandro system
Can you give "emerge -uDtp world" output when it is wanting to *downgrade*, please? bagual root # emerge -uDtp world These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [nomerge ] media-video/ati-drivers-3.14.6 [ebuild UD] x11-base/xorg-x11-6.7.0-r3 [6.8.0-r4] And after a emerge --sync: bagual root # date Mon Jan 31 01:20:16 BRST 2005 bagual root # emerge -uDtp world These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [nomerge ] media-plugins/xmms-xmmsmplayer-0.5 [nomerge ] media-video/mplayer-1.0_pre5-r5 [ebuild U ] media-libs/win32codecs-20050115 [20040916-r1] [nomerge ] media-video/ati-drivers-3.14.6 [ebuild UD] x11-base/xorg-x11-6.7.0-r3 [6.8.0-r4] [nomerge ] x11-terms/xterm-197 [nomerge ] sys-apps/utempter-0.5.5.5-r1 [nomerge ] app-arch/rpm2targz-9.0-r2 [ebuild U ] app-arch/cpio-2.6-r1 [2.5] ati-drivers-3.14.6 requires <x11-base/xorg-x11-6.7.99. So, if you wish to use ati-drivers, you're probably best-off masking >=x11-base/xorg-x11-6.8. Once this bug is fixed, that is essentially the behavior that you will get. *** Bug 84198 has been marked as a duplicate of this bug. *** Packages having issues like ati-drivers should probably block the opposite direction of the requirement... so block all newer xorgs. Assuming that is reasonable for the package. I'm seeing this effect with valgrind 2.2.0-r2 and 2.4.0 now (with package keyword ~x86). Please. The cause of this bug is known. How to fix it is known. It's not a small task but is being worked on. Please don't waste time by causing more junk mail. *** Bug 57269 has been marked as a duplicate of this bug. *** *** Bug 90786 has been marked as a duplicate of this bug. *** *** Bug 67677 has been marked as a duplicate of this bug. *** (In reply to comment #37) > Please. The cause of this bug is known. How to fix it is known. It's not a small task but is being worked on. Please don't waste time by causing more junk mail. Ok, I can understand your frustration from feeling pressured. I hope you can understand a users frustration from feeling ignored. After 3 years, can you, please, at least give a short explanation on what the problem really is ? Portage ignores dependencies on a package if it is already installed. By package you mean package-<version>, not just package name, right ? So portage thinks that by updating foo-1.0 to foo-2.0 nothing will be broken, since it does not actually look at what depends on foo-1.0. On the next update foo-1.0 is no longer installed, so portage finds out that apps depend on it and wants to downgrade foo-2.0 to foo-1.0 . Am I understanding it right ? *** Bug 102208 has been marked as a duplicate of this bug. *** (In reply to comment #43) > > Am I understanding it right ? At least here one upgrade/downgrade cycle was caused by having one of the deps in the world file. Both callgrind and valgrind are in the world file so here is what happens: It seems portage goes trough all the items one by one so when it looks at callgrind it does not want to update valgrind because the dep is =2*, but when it comes to valgrind it does want to update it because it does not check for anything else. So with emerge -uD world valgrind goes up to 3.0.0 and back again with callgrind installed. Hopefully this explained at least one possible cause of this problem. I recommend using emerge -uDpvt in tracking the problem you might have. > I recommend using emerge -uDpvt in tracking the
> problem you might have.
That's what I am currently doing. Hopefully, now that portage-2.1.0_alpha20050718
is in portage, this bug will be soon dead and buried.
i have observed valgrind problem from bug 102208 and now as an addition, while doing #emerge -Dupv world I see: [ebuild UD] dev-util/valgrind-2.4.1 [3.0.0] +X [ebuild U ] dev-util/valgrind-3.0.1 [3.0.0] +X how about that? *** This bug has been marked as a duplicate of 1343 *** For the time being, if people are pointed to this bug, with the proper amount of
version masking and unmasking, one can combat this issue [somewhat]. For me it
was gtk+, and by adding the following lines, I could keep a stable version of
the gtk+1.2.x branch and also use gtk+2.8.8:
portage.mask:
>x11-libs/gtk+-2.8.8 #mask all versions higher than 2.8.8.
#...
<x11-libs/gtk+-2.8.8 #mask all versions less than 2.8.8
portage.unmask:
<x11-libs/gtk+-2.0 #unmask all versions less than 2.0
I know it's a bit barbaric and I could have accomplished the same with 2 lines,
but at least it gets rid of the annoying 2.6.10-r[blah] recompile message.
I try making a quick and dirty script for package masking/unmasking management
after my school quarter ends.
*** Bug 142848 has been marked as a duplicate of this bug. *** *** Bug 278568 has been marked as a duplicate of this bug. *** |
