-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature request - add: equo preservedlibs why #41
Comments
Can you check if the following command does the job for you?
And can you elaborate on this?
|
@Enlik seems like
I would vouch for making As for 'direct cause of preservation', I was referring to what package depends on the dependency that is broken. In the example above, I guess that for this last point what I'd like to have is a command that could easily answer: "Which package installed by me is leading to the breakage?" and "Is the breakage my fault for using portage or is this an issue with Sabayon packages?". One way I could see this working would be to list the revdep tree of a lib all the way to the packages that are registered in the 'world` set (i.e. installed by user/admin as opposed to automatically as a dependency):
|
Let's split it up.
|
With regards to the second point, I reached
Makes me wonder if showing:
instead of the output of The third point is perhaps the major feature which would make sense under |
I was thinking about something you mentioned, although in a simpler form. Something like:
Anyway, that's not the real issue here. So you want to have a direct "cause" of the problem, up to the root of reverse dependency tree (package from world/installed by user), also with information about the origin next to each node. I'll ask to get some more input about this so we can think it's desired or not (as a whole; the improvement about reading also world file etc. would be useful by itself). What's on my mind:
# this is not real code
pkgs=$(equo [get broken packages])
for p in $pkgs; do
equo match "$p" [show the origin (a) / show direct revdeps (b) / show all revdep tree (c)]
done (or whatever else, as needed) Leaving it open for further discussion and ideas. Gladly, the main issue, i.e. built-in command to provide more information (-v) was found. PS From personal experience, it's a good idea to turn off ignore-spm-downgrade and see what would be "updated" either permanenty or once per while (https://bugs.sabayon.org/show_bug.cgi?id=5547, "ignore-spm-downgrades shouldn't necessarily ignore actual updates"). |
Currently the output of
equo preservedlibs list
also present at the end ofequo upgrade
orequo install
lists libs and their original packages but not which packages are causing the libraries to be kept.This wiki article mentions a workaround for this limitation but from my experience the packages listed may not be the direct cause of the 'preservation'.
Instead I had to resort to
equo remove --pretend <package-reported-by-entropypreservedlibs>
and inspect the list of software that would be removed to find the culprit.Another informative command was
equo query required <lib.so>
which allowed identifying which packages depend on some of the libs, although one has to use the right-hand side of the output ofequo preservedlibs
.In short, entropy seems to have all the necessary machinery to provide a more user-friendly or informative output. While this machinery is mostly useful on systems that mix entropy and portage packages, it occasionally happens that entropy packages also need to preserve libs.
The proposed command
equo preservedlibs why
would produce an output of this sort:Alternatively, inverting the output to aggregate on the packages causing the issue:
The text was updated successfully, but these errors were encountered: