On Tue, Jan 13, 2009 at 11:27 AM, Willie Wong <ww...@princeton.edu> wrote: > On Tue, Jan 13, 2009 at 11:10:44AM -0600, Paul Hartman wrote: >> On Tue, Jan 13, 2009 at 10:57 AM, Willie Wong <ww...@princeton.edu> wrote: >> > Hum, I seem to have made an erroneous assumption. >> > >> > On Tue, Jan 13, 2009 at 11:38:05AM -0500, Willie Wong wrote: >> >> The problem with this last one is not --deep. It is --update. >> > >> > Nevermind, I looked at the changelogs for openoffice and >> > dev-perl/Archive-Zip, and frankly, I am pretty sure what I said was >> > completely wrong in this situation. And also, frankly, I am becoming >> > as confused as you are about your problem. >> >> I "downgraded" to File-Spec-3.29 (actually an upgrade) which in turn >> emerged/updated the rest of that bunch of perl-related packages. Now >> I'm re-emerging openoffice-3.0.0 since it appears to be using a newer >> set of the go-oo.org patches (despite the lack of version number >> change). Plus it is always fun to see how long it takes to build one >> of the biggest packages there is. I have emerged it twice in the past, >> the first was 1hr33m the second was 1hr55m, so I hope this one won't >> exceed 2h. > > I don't find that explanation satisfactory. (The one about upgrade vs > downgrades.) -u expands to --update means to install the *best > available version*, not the *highest version number available*. If an > ebuild goes from x86 to being hardmasked, --update should downgrade. > If an ebuild of insanely high version number gets removed, --update > should downgrade. > > I can explain why emerge openoffice and emerge --deep openoffice are > different. emerge --deep openoffice basically does something similar > to emerge --oneshot <everything openoffice has in its dependency>. > So every package in the dependency tree will be considered, and if not > at the *best* version it will be updated. Compare to emerge openoffice > where only if a change of ebuild in openoffice changes the dependency > will trigger installation of new or updated versions of dependencies. > (Basically, you already have a version of whatever perl class it > wants, and the ebuild specifies >= some really low version, so the > dependency is satisfied and won't be considered in the emerge.) > > What I can't explain is why emerge --update --deep world misses the > update! dev-perl/Archive-Zip is (correct me if I am wrong: I didn't > see it mentioned in the changelogs so I assume it was not changed) in > the dependency tree of both the Nov 3 and the January versions of > openoffice. So --deep should traverse down there and find that one of > its dependencies requires an update. At least that's what I expect > based on "man emerge".
Well, Archive-Zip had File-Spec as a dep, which was a downgrade. If you check the Changelog in perl-core/File-Spec you can see where they renamed the version number from 3.2701 to 3.27.01. Apparently I had installed it under the "old" version number, 3.2701 which later got renamed to 3.27.01 and was superseded by 3.29. Since 2701 wasn't masked, it just disappeared from portage and stayed happily in my system installed packages cache, and emerge saw my current version 2701 as a higher version number than 27.01 or 29 so it never "upgraded" me to the newer version. That's my guess, anyway. Would those packages which are installed but no longer in my portage tree or one of its overlays be identified by a [?] in "emerge -evp world" output? Along that same line of thought, it might be interesting to make a script to compare the cached ebuilds of installed packages against the same version ebuilds in the portage tree to see if there were any "stealth" updates other than openoffice. Paul
