View previous topic :: View next topic |
Author |
Message |
gtwrek Tux's lil' helper
Joined: 10 Mar 2017 Posts: 112 Location: San Jose, CA
|
Posted: Thu Mar 15, 2018 3:26 pm Post subject: Trouble with a depclean |
|
|
As part of my usual gentoo box maintenance, I run glsa-check regularly. A recent item has had me puzzled for a while, and I'd like to solve it:
Code: | % glsa-check -p affected
Checking GLSA 201610-04
>>> No upgrade path exists for these packages:
dev-libs/libgcrypt-1.5.6-r101
|
Ok, let's try and remove the problem package:
Code: | % emerge -pv --depclean "=dev-libs/libgcrypt-1.5.6-r101"
Calculating dependencies... done!
dev-libs/libgcrypt-1.5.6-r101 pulled in by:
app-emulation/vmware-player-12.1.0.3272444-r2 requires dev-libs/libgcrypt:11/11
|
Ok, vmware. I don't use that anymore - switched to qemu, so let's just remove vmware too. After a few attempts to get all the required packages:
Code: | % emerge -pv --depclean "=dev-libs/libgcrypt-1.5.6-r101" "=app-emulation/vmware-player-12.1.0.3272444-r2" "=app-emulation/vmware-modules-308.1.0" "=app-emulation/vmware-player-12.1.0.3272444-r2"
Calculating dependencies... done!
>>> Checking for lib consumers...
>>> Assigning files to packages...
* In order to avoid breakage of link level dependencies, one or more
* packages will not be removed. This can be solved by rebuilding the
* packages that pulled them in.
*
* app-emulation/vmware-player-12.1.0.3272444-r2 pulled in by:
* app-accessibility/at-spi2-atk-2.22.0 needs libglib-2.0.so.0
* app-accessibility/at-spi2-core-2.22.1 needs libglib-2.0.so.0
... and a whole lot more...
|
I don't know how to interpret that last one, nor solve it. It seems to be listing every package that depends on libglib-2.0, but somehow tying this dependency to vmware-player. This make no sense to me, and I don't know how to solve.
I did a world update a few weeks ago. So "Rebuilding the packages that pulled them in" doesn't seem to have solved things.
Any hints?
Thanks,
Mark |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Thu Mar 15, 2018 4:00 pm Post subject: |
|
|
Well, if vmware-player do provide that library, if packages were built using that lib, it mean removing vmplayer would break them.
And the hint is: to not break them, rebuild them but using another library implementation or not using that library.
It's something easy to do if you can remove the dependency on the library, it's something harder if you have a different implementation to link against (because the "old" implementation is still there and will be reuse).
To remove the dep it mean generally removing a useflag to not depends on it anymore, and to replace with a different implementation of a lib, it mean, accept the packages that depends on it will be broken while you remove old implementation and install new one (which may not be safe!).
Let's assume depclean is reporting right, and the packages do depends on a libglib that is provide by vmware-player (yeah seems strange for me too, as the lib is provide by glib, but if vmware-player was a binary package, many binary package install their own version of some libs).
What i would do if i were you:
* quickpkg the package list (better safe than sorry)
* emerge -C vm-ware and friends (but not the packages that complain for the lib)
* install glib to provide a new libglib if need
* revdep-rebuild -L libglib-2.0.so.0 (this will rebuild all packages that use that lib version, so your at-spi2-atk-2.22.0...) |
|
Back to top |
|
|
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Thu Mar 15, 2018 6:22 pm Post subject: |
|
|
I'd keep it simpler. dev-libs/libgcrypt should not be in the world file at all. You can check what is pulling it by running equery d libgcrypt and you may be surprised at the list as I highly doubt vm-player is the only package pulling that particular library.
you can then do an emerge -c <package> at only the the top level packages, in this case emerge -c app-emulation/vmware-player then follow that with an emerge -ac. Since it isn't being pulled it should go quietly without confusing portage. _________________ First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
Back to top |
|
|
gtwrek Tux's lil' helper
Joined: 10 Mar 2017 Posts: 112 Location: San Jose, CA
|
Posted: Thu Mar 15, 2018 9:20 pm Post subject: |
|
|
I'd already started krinn's suggestions. Mostly ok. But I'm running into the more "normal" portage issues in his last step of doing the revdep-rebuild. Seeing all sorts on blocks/and conflicts with respect to glib versions, and gdbus-codegen.
But these are at least the "normal" set of portage problems I can normally fumble my way through given some time.
I'll keep on plugging away at it, and list any resolution here.
Thanks for the help and pointers.
Regards,
Mark |
|
Back to top |
|
|
gtwrek Tux's lil' helper
Joined: 10 Mar 2017 Posts: 112 Location: San Jose, CA
|
Posted: Sat Mar 17, 2018 8:02 pm Post subject: |
|
|
Again thanks for the suggestions. I did as Krinn suggested. As mentioned I had some troubles with the revdep-rebuild, but got everything to work.
My glsa_check runs clean again.
Regards,
Mark |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|