From: Paul Hartman <paul.hartman+gentoo@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] 'emerge -e world' question
Date: Tue, 13 Jan 2009 11:45:15 -0600 [thread overview]
Message-ID: <58965d8a0901130945s45d6f5b7v3aa27027ff48e07b@mail.gmail.com> (raw)
In-Reply-To: <20090113172748.GA7589@math.princeton.edu>
On Tue, Jan 13, 2009 at 11:27 AM, Willie Wong <wwong@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 <wwong@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
next prev parent reply other threads:[~2009-01-13 17:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 15:44 [gentoo-user] 'emerge -e world' question Paul Hartman
2009-01-13 15:47 ` [gentoo-user] " Paul Hartman
2009-01-13 23:55 ` b.n.
2009-01-14 0:05 ` Paul Hartman
2009-01-14 0:18 ` Willie Wong
2009-01-14 0:26 ` »Q«
2009-01-13 15:52 ` [gentoo-user] " Alan McKinnon
2009-01-13 16:02 ` Mike Kazantsev
2009-01-13 16:25 ` Paul Hartman
2009-01-13 16:41 ` Albert Hopkins
2009-01-13 16:20 ` Paul Hartman
2009-01-13 16:37 ` Paul Hartman
2009-01-13 16:38 ` Willie Wong
2009-01-13 16:57 ` Willie Wong
2009-01-13 17:10 ` Paul Hartman
2009-01-13 17:27 ` Willie Wong
2009-01-13 17:45 ` Paul Hartman [this message]
2009-01-13 16:02 ` Albert Hopkins
2009-01-13 20:28 ` Dale
2009-01-13 20:37 ` Paul Hartman
2009-01-13 21:02 ` Dale
2009-01-13 21:18 ` Paul Hartman
2009-01-13 21:20 ` Neil Bothwick
2009-01-13 22:26 ` Dale
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58965d8a0901130945s45d6f5b7v3aa27027ff48e07b@mail.gmail.com \
--to=paul.hartman+gentoo@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox