| 1 |
On Tue, 17 Apr 2012 18:41:55 +0300 |
| 2 |
Nikos Chantziaras <realnc@×××××.com> wrote: |
| 3 |
|
| 4 |
> On 17/04/12 18:34, Nikos Chantziaras wrote: |
| 5 |
> > On 17/04/12 18:10, Alan McKinnon wrote: |
| 6 |
> >> On Tue, 17 Apr 2012 18:01:43 +0300 |
| 7 |
> >> Nikos Chantziaras<realnc@×××××.com> wrote: |
| 8 |
> >> |
| 9 |
> >>> emerge --depclean seems to have bugged out for me: |
| 10 |
> >>> |
| 11 |
> >>> * Dependencies could not be completely resolved due to |
| 12 |
> >>> * the following required packages not being installed: |
| 13 |
> >>> * |
| 14 |
> >>> * =dev-libs/openssl-0.9.8* pulled in by: |
| 15 |
> >>> * app-emulation/vmware-workstation-8.0.2.591240 |
| 16 |
> >>> * |
| 17 |
> >>> * dev-libs/openssl:0.9.8 pulled in by: |
| 18 |
> >>> * www-client/google-chrome-19.0.1084.24_beta131971 |
| 19 |
> >>> |
| 20 |
> >>> It says to do a "emerge --update --newuse --deep --with-bdeps=y |
| 21 |
> >>> @world". Which is what I just did to begin with (and running it |
| 22 |
> >>> again doesn't result in anything getting emerged.) |
| 23 |
> >>> |
| 24 |
> >>> It also says: |
| 25 |
> >>> |
| 26 |
> >>> * Also, note that it may be necessary to manually uninstall |
| 27 |
> >>> * packages that no longer exist in the portage tree, since it may |
| 28 |
> >>> * not be possible to satisfy their dependencies. |
| 29 |
> >>> |
| 30 |
> >>> However, dev-libs/openssl is installed and seems to be in the |
| 31 |
> >>> tree: |
| 32 |
> >>> |
| 33 |
> >>> $ eix -e dev-libs/openssl |
| 34 |
> >>> [I] dev-libs/openssl |
| 35 |
> >>> Available versions: |
| 36 |
> >>> (0.9.8) 0.9.8r (~)0.9.8s 0.9.8s-r1 0.9.8t 0.9.8u |
| 37 |
> >>> (0) 1.0.0d 1.0.0e (~)1.0.0e-r1 (~)1.0.0f 1.0.0f-r1 |
| 38 |
> >>> 1.0.0g 1.0.0h **1.0.1 |
| 39 |
> >>> {{bindist gmp kerberos rfc3779 sse2 static-libs test vanilla |
| 40 |
> >>> zlib}} Installed versions: 0.9.8u(0.9.8)(22:32:12 12/03/12)(sse2 |
| 41 |
> >>> zlib -bindist -gmp -kerberos -test) 1.0.0h(22:33:20 12/03/12)(sse2 |
| 42 |
> >>> zlib -bindist -gmp -kerberos -rfc3779 -static-libs -test) |
| 43 |
> >>> |
| 44 |
> >>> |
| 45 |
> >> |
| 46 |
> >> I think you should file a bug against www-client/google-chrome |
| 47 |
> >> |
| 48 |
> >> It wants the exact version dev-libs/openssl:0.9.8 but the oldest in |
| 49 |
> >> portage is dev-libs/openssl:0.9.8r |
| 50 |
> >> |
| 51 |
> >> Chances are the dev simply left off the version suffix by accident |
| 52 |
> > |
| 53 |
> > That can't be it. There's a wildcard at the end: |
| 54 |
> > |
| 55 |
> > =dev-libs/openssl-0.9.8* |
| 56 |
> > |
| 57 |
> > which should match 0.9.8u. |
| 58 |
> |
| 59 |
> No wait, that's vmware. The chrome ebuild pulls a slot: |
| 60 |
> |
| 61 |
> dev-libs/openssl:0.9.8 |
| 62 |
> |
| 63 |
> This also matches correctly. The 0.9.8 slot matches all those |
| 64 |
> versions. So no problem with that either. |
| 65 |
|
| 66 |
I missed that colon for the slot. |
| 67 |
So this certainly looks buggy on the part of depclean. Now to find out |
| 68 |
what's going on. |
| 69 |
|
| 70 |
One thing that strikes me as a possibility is that the highest numbered |
| 71 |
version has the lower slot number (0). I know that SLOT names are |
| 72 |
just names and not supposed to be treated like they form an order, but |
| 73 |
I've seen odd things like this before. I think KDE did it to me once. |
| 74 |
|
| 75 |
What happens if you emerge openssl:0.9.8, let it go into world, then |
| 76 |
run depclean? The build takes 2 minutes and you can easily remove it |
| 77 |
from world later. |
| 78 |
|
| 79 |
-- |
| 80 |
Alan McKinnnon |
| 81 |
alan.mckinnon@×××××.com |
Archives