Gentoo Archives: gentoo-user

From: gottlieb@×××.edu
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] updating ALL packages
Date: Fri, 25 Jul 2014 14:43:12
Message-Id: 87ha25jy8g.fsf@nyu.edu
In Reply to: Re: [gentoo-user] updating ALL packages by Alan McKinnon
1 On Fri, Jul 25 2014, Alan McKinnon wrote:
2
3 > On 25/07/2014 03:51, gottlieb@×××.edu wrote:
4 >> On Thu, Jul 24 2014, Neil Bothwick wrote:
5 >>
6 >>> On Wed, 23 Jul 2014 09:24:44 -0400, gottlieb@×××.edu wrote:
7 >>>
8 >>>> I had mistakenly thought this would update all packages not at the
9 >>>> latest version (subject to package.accept_keywords, package.mask, ...).
10 >>>
11 >>> It only updates runtime dependencies, you need --with-bdeps=y to update
12 >>> all dependencies.
13 >>
14 >> Thank you and michael for this point.
15 >>
16 >>> However, the default is no for a good reason, there's no need to
17 >>> update build time deps once the package is installed.
18 >>
19 >> I see.
20 >>
21 >>>> I now realize that it only does this for the packages in world and then
22 >>>> follows the dependency tree. So if package A in world is up to date, A
23 >>>> depends of B, and a new version of B appears, B will not be updated.
24 >>>>
25 >>>> As a result eix-test-obsolete finds that I have packages installed that
26 >>>> are no longer in the database.
27 >>>
28 >>> That shouldn't happen. If an installed package is removed for the tree,
29 >>> portage should either install the highest version that matches your
30 >>> settings or print a warning.
31 >>
32 >> I am not sure if you consider the message from eix-test-obsolete
33 >> as the message from portage.
34 >>
35 >> eix-test-obsolete prints (among other things)
36 >>
37 >> Installed packages with a version not in the database (or masked):
38 >> [lines omitted]
39 >> [U] virtual/perl-CPAN-Meta-Requirements (2.125.0@10/29/2013 ->
40 >> (~)2.125.0-r1): Virtual for CPAN-Meta-Requirements
41 >>
42 >> eix virtual/perl-CPAN-Meta-Requirements prints
43 >>
44 >> [U] virtual/perl-CPAN-Meta-Requirements
45 >> Available versions: 2.122.0-r2 (~)2.125.0-r1
46 >> Installed versions: 2.125.0(09:25:35 PM 10/29/2013)
47 >>
48 >> /etc/portage/package.accept_keywords/goingstable contains
49 >> ~virtual/perl-CPAN-Meta-Requirements-2.125.0
50 >>
51 >> I thought this would be updated to 2.125.0-r1 but
52 >> my update world (withOUT bdeps=y) says nothing to merge
53 >> and prints no error or warning
54 >
55 > That is correct. The package is needed to build stuff and nothing in the
56 > current list of packages to be built needs the package to do it.
57 > Should you sometime update a package that does depend on perl-CPAN-Meta
58 > to be built, then perl-CPAN-Meta will then be updated
59 >
60 >
61 >
62 >>>> I could do
63 >>>>
64 >>>> emerge --update the-2-dozen-such-packages
65 >>>>
66 >>>> Is that wise?
67 >>>
68 >>> No, as it will add them to world (this behaviour of -u appears to vary
69 >>> depending on portage version, wind direction and sunspot activity). Use
70 >>> --oneshot.
71 >>
72 >> Understood. And I remember the discussion on the list about the meaning
73 >> of -u.
74 >>
75 >> emerge -u -1 virtual/perl-CPAN-Meta-Requirements
76 >> reveals what is probably my real problem
77 >>
78 >> [ebuild U ~] virtual/perl-CPAN-Meta-Requirements-2.125.0-r1 [2.125.0] 0 kB
79 >> [nomerge ] perl-core/CPAN-Meta-Requirements-2.125.0
80 >> [ebuild UD ] virtual/perl-version-0.990.100 [0.990.400] 0 kB
81 >> [ebuild UD ] perl-core/version-0.990.100 [0.990.400] 105 kB
82 >>
83 >> upgrading virtual/perl-CPAN-Meta-Requirements entails downgrading two
84 >> other perl packages (or bumping their version in goingstable, which I
85 >> remember you suggest).
86 >>
87 >> I am going away for 2 weeks, but when I return I will look carefully at
88 >> the (mostly perl) files that eix-test-obsolete complains about. I am
89 >> hopeful that armed with emerge -u -1 and/or --with-bdeps=y I can remove
90 >> the warnings from eix-test-obsolete.
91 >
92 > Just do one world update with bdeps=y
93 >
94 > Portage will then update the packages that it has been skipping
95 >
96 Not quite that simple due to the bothwick
97 package.accept_keywords/goingstable. I did a --pretend run and saw
98 several proposed downgrades (to packages required by the ones mentioned
99 in eix-test-obsolete). Neil recommends that in these cases I update
100 goingstable to permit upgrades instead.
101
102 thanks for your interest and help
103 allan