Ticket #1281 (new defect)

Opened 4 years ago

Last modified 4 years ago

fix-linkage does not follow dependency chain

Reported by: exitheone Owned by:
Priority: Sometime Milestone:
Component: clients/cave Version: 1.4.0
Keywords: fix-linkage dependencies Cc:
Blocked By: Blocking:
Distribution: Gentoo

Description

Hi, I noticed on a highly broken system (libpng, libjpeg and icu broken) that cave fix-linkage does not follow the dependency chain.

The following situation occurred: app-text/gtkspell was broken because my libpng was messed up x11-libs/cairo was also broken because of libpng

Now fix-linkage tried to build gtkspell first although it also depends on cairo. Gtkspell failed to build because cairo was broken and fix-linkage failed. I had to first manually resolve cairo and then run fix-linkage again so make it work.

Change History

comment:1 Changed 4 years ago by ciaranm

It should follow ELF dependencies to figure out broken packages, and then package dependencies to figure out a resolve ordering. Are you sure proper dependency information was available?

comment:2 Changed 4 years ago by exitheone

Yes, gtkspell depends on x11-libs/gtk+ which depends on x11-libs/cairo, so the dependency chain should imho be intact.

comment:3 Changed 4 years ago by ciaranm

And did cairo have broken ELFs?

comment:4 Changed 4 years ago by exitheone

Yes, it did, it was just in the fix-linkage list after gtkspell

comment:5 Changed 4 years ago by exitheone

If this information is somehow useful:

Maybe it has something to do with the magnitude of the breakage, fix-linkage listed 227 packages for me, all depending on libpng, libjpeg and icu

comment:6 Changed 4 years ago by ciaranm

The thing is... We do use dependency information for fix-linkage, and we mark "broken" packages as unusable for cycle resolution. So there's something happening here that you're not telling us about. If cairo was definitely detected as being broken, and if no package has an unlisted dependency that's mucking things up, then I'm not sure what else that could be.

comment:7 Changed 4 years ago by exitheone

I will try to reproduce the situation later in a chroot by just deleting icu libpng and libjpeg and see if that helps somehow.

Note: See TracTickets for help on using tickets.