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