1 |
Duncan wrote: |
2 |
> I've been noticing this for a couple revisions I think, but am not sure if |
3 |
> it's new behavior or if I'm just noticing what's been there all along. |
4 |
> |
5 |
> At the end of a new package merge, after the binpkg tarball (I'm using |
6 |
> FEATURES=binpkg) has been created, then decompressed and merged, but |
7 |
> before the emerge --clean phase unmerges old versions, I'm seeing what |
8 |
> appears to be an incorrect but harmless message. Here's what I get for |
9 |
> gcc, so you can see the sequence (the three lines, safely unmerging thru |
10 |
> original instance unmerged, is what I'm talking about): |
11 |
> |
12 |
> |
13 |
>>>>/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1/x86_64-pc-linux-gnu-gcc-4.1.1 -> x86_64-pc-linux-gnu-gcc |
14 |
>>>>Safely unmerging already-installed instance... |
15 |
> |
16 |
> No package files given... Grabbing a set. |
17 |
> |
18 |
>>>>Original instance of package unmerged safely. |
19 |
> |
20 |
> * The current gcc config appears valid, so it will not be |
21 |
> * automatically switched for you. If you would like to |
22 |
> * switch to the newly installed gcc version, do the |
23 |
> * following: |
24 |
> |
25 |
> * eselect compiler set <profile> |
26 |
> |
27 |
> |
28 |
> * If you have issues with packages unable to locate libstdc++.la, |
29 |
> * then try running 'fix_libtool_files.sh' on the old gcc versions. |
30 |
> |
31 |
> |
32 |
>>>>Regenerating /etc/ld.so.cache... |
33 |
>>>>sys-devel/gcc-4.1.1 merged. |
34 |
> |
35 |
> |
36 |
>>>>No packages selected for removal by clean. |
37 |
> |
38 |
> |
39 |
>>>>Auto-cleaning packages... |
40 |
> |
41 |
> |
42 |
> /What/ already-installed instance? It's a /new/ version of the package, |
43 |
> so there was no already installed instance to unmerge. Again, this is |
44 |
> before the clean phase, which occurs just after that, and which removes |
45 |
> the old version as expected, so it's not that. |
46 |
> |
47 |
> I know the message itself isn't new, and I'm used to seeing it when I'm |
48 |
> remerging a package over itself, where the message makes sense. Why is it |
49 |
> showing up here, when it's a new package version, so there's no original |
50 |
> instance to unmerge? Is this new behavior or has it always done that and I |
51 |
> never noticed it until now? |
52 |
> |
53 |
|
54 |
Looking at the code I'd guess you'd never noticed, I don't see any |
55 |
commits in treewalk lately, it should occur for all packages. |
56 |
-- |
57 |
gentoo-portage-dev@g.o mailing list |