Skip to content
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

Open
unode opened this issue Feb 13, 2018 · 5 comments
Open

feature request - add: equo preservedlibs why #41

unode opened this issue Feb 13, 2018 · 5 comments

Comments

@unode
Copy link

unode commented Feb 13, 2018

Currently the output of equo preservedlibs list also present at the end of equo upgrade or equo 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 of equo 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:

$ equo preservedlibs why
╠ /usr/lib64/libmysqlclient.so.18 [libmariadb.so.3:2 -> dev-db/mariadb-10.2.12] - due to: {dev-perl/DBD-mysql-4.44.0 dev-qt/qtsql-4.8.7-r1 dev-qt/qtsql-5.9.4}
╠ /usr/lib64/libboost_thread.so.1.63.0 [libboost_thread.so.1.63.0:2 -> dev-libs/boost-1.63.0] - due to: {sci-mathematics/rstudio-1.1.383}
╠ /usr/lib64/libboost_system.so.1.63.0 [libboost_system.so.1.63.0:2 -> dev-libs/boost-1.63.0] - due to: {sci-mathematics/rstudio-1.1.383}
╠ /usr/lib64/libboost_signals.so.1.63.0 [libboost_signals.so.1.63.0:2 -> dev-libs/boost-1.63.0] - due to: {sci-mathematics/rstudio-1.1.383}
╠ /usr/lib64/libboost_regex.so.1.63.0 [libboost_regex.so.1.63.0:2 -> dev-libs/boost-1.63.0] - due to: {sci-mathematics/rstudio-1.1.383}
╠ /usr/lib64/libboost_program_options.so.1.63.0 [libboost_program_options.so.1.63.0:2 -> dev- libs/boost-1.63.0] - due to: {sci-mathematics/rstudio-1.1.383}
╠ /usr/lib64/libboost_iostreams.so.1.63.0 [libboost_iostreams.so.1.63.0:2 -> dev-libs/boost-1.63.0] - due to: {sci-mathematics/rstudio-1.1.383}
╠ /usr/lib64/libboost_filesystem.so.1.63.0 [libboost_filesystem.so.1.63.0:2 -> dev-libs/boost-1.63.0] - due to: {sci-mathematics/rstudio-1.1.383}
╠ /usr/lib64/libboost_date_time.so.1.63.0 [libboost_date_time.so.1.63.0:2 -> dev-libs/boost-1.63.0] - due to: {sci-mathematics/rstudio-1.1.383}

Alternatively, inverting the output to aggregate on the packages causing the issue:

$ equo preservedlibs why
The following packages are causing libs to be preserved:
 * dev-perl/DBD-mysql-4.44.0
   - /usr/lib64/libmysqlclient.so.18 [libmariadb.so.3:2 -> dev-db/mariadb-10.2.12]
 * dev-qt/qtsql-4.8.7-r1
   - /usr/lib64/libmysqlclient.so.18 [libmariadb.so.3:2 -> dev-db/mariadb-10.2.12]
 * dev-qt/qtsql-5.9.4
   - /usr/lib64/libmysqlclient.so.18 [libmariadb.so.3:2 -> dev-db/mariadb-10.2.12]
 * sci-mathematics/rstudio-1.1.383
   - /usr/lib64/libboost_thread.so.1.63.0 [libboost_thread.so.1.63.0:2 -> dev-libs/boost-1.63.0]
   - /usr/lib64/libboost_system.so.1.63.0 [libboost_system.so.1.63.0:2 -> dev-libs/boost-1.63.0]
   - /usr/lib64/libboost_signals.so.1.63.0 [libboost_signals.so.1.63.0:2 -> dev-libs/boost-1.63.0]
   - /usr/lib64/libboost_regex.so.1.63.0 [libboost_regex.so.1.63.0:2 -> dev-libs/boost-1.63.0]
   - /usr/lib64/libboost_program_options.so.1.63.0 [libboost_program_options.so.1.63.0:2 -> dev-libs/boost-1.63.0]
   - /usr/lib64/libboost_iostreams.so.1.63.0 [libboost_iostreams.so.1.63.0:2 -> dev-libs/boost-1.63.0]
   - /usr/lib64/libboost_filesystem.so.1.63.0 [libboost_filesystem.so.1.63.0:2 -> dev-libs/boost-1.63.0]
   - /usr/lib64/libboost_date_time.so.1.63.0 [libboost_date_time.so.1.63.0:2 -> dev-libs/boost-1.63.0]
@Enlik
Copy link
Member

Enlik commented Feb 28, 2018

Can you check if the following command does the job for you?

# equo preservedlibs list -v

And can you elaborate on this?

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'.

@unode
Copy link
Author

unode commented Mar 3, 2018

@Enlik seems like -v does the trick:

# equo preservedlibs list -v
╠ /usr/lib64/libmysqlclient.so.18 [libmariadb.so.3:2 -> dev-db/mariadb-10.2.12], needed by:
╠  -> dev-qt/qtsql-4.8.7-r1
╠  -> dev-qt/qtsql-5.9.4
╠  -> dev-perl/DBD-mysql-4.44.0
╠ /usr/lib64/libmariadb.so.3 [libmariadb.so.3:2 -> dev-db/mariadb-10.2.12], needed by:
╠  -> dev-qt/qtsql-4.8.7-r1
╠  -> dev-qt/qtsql-5.9.4
╠  -> dev-perl/DBD-mysql-4.44.0
╠ /usr/lib64/libmariadb.so [libmariadb.so.3:2 -> dev-db/mariadb-10.2.12], needed by:
╠  -> dev-qt/qtsql-4.8.7-r1
╠  -> dev-qt/qtsql-5.9.4
╠  -> dev-perl/DBD-mysql-4.44.0
╠ /usr/lib32/libmysqlclient.so.18 [libmariadb.so.3:1 -> dev-db/mariadb-10.2.12], needed by:
╠  -> dev-qt/qtsql-4.8.7-r1
╠ /usr/lib32/libmariadb.so.3 [libmariadb.so.3:1 -> dev-db/mariadb-10.2.12], needed by:
╠  -> dev-qt/qtsql-4.8.7-r1
╠ /usr/lib32/libmariadb.so [libmariadb.so.3:1 -> dev-db/mariadb-10.2.12], needed by:
╠  -> dev-qt/qtsql-4.8.7-r1
╠ /usr/lib64/libboost_thread.so.1.63.0 [libboost_thread.so.1.63.0:2 -> dev-libs/boost-1.63.0], needed by:
╠  -> sci-mathematics/rstudio-1.1.383
╠ /usr/lib64/libboost_system.so.1.63.0 [libboost_system.so.1.63.0:2 -> dev-libs/boost-1.63.0], needed by:
╠  -> sci-mathematics/rstudio-1.1.383
╠ /usr/lib64/libboost_signals.so.1.63.0 [libboost_signals.so.1.63.0:2 -> dev-libs/boost-1.63.0], needed by:
╠  -> sci-mathematics/rstudio-1.1.383
╠ /usr/lib64/libboost_regex.so.1.63.0 [libboost_regex.so.1.63.0:2 -> dev-libs/boost-1.63.0], needed by:
╠  -> sci-mathematics/rstudio-1.1.383
╠ /usr/lib64/libboost_program_options.so.1.63.0 [libboost_program_options.so.1.63.0:2 -> dev-libs/boost-1.63.0], needed by:
╠  -> sci-mathematics/rstudio-1.1.383
╠ /usr/lib64/libboost_iostreams.so.1.63.0 [libboost_iostreams.so.1.63.0:2 -> dev-libs/boost-1.63.0], needed by:
╠  -> sci-mathematics/rstudio-1.1.383
╠ /usr/lib64/libboost_filesystem.so.1.63.0 [libboost_filesystem.so.1.63.0:2 -> dev-libs/boost-1.63.0], needed by:
╠  -> sci-mathematics/rstudio-1.1.383
╠ /usr/lib64/libboost_date_time.so.1.63.0 [libboost_date_time.so.1.63.0:2 -> dev-libs/boost-1.63.0], needed by:
╠  -> sci-mathematics/rstudio-1.1.383

I would vouch for making -v the default mode. The extra output is mostly harmless and quite beneficial/helpful.

As for 'direct cause of preservation', I was referring to what package depends on the dependency that is broken. In the example above, rstudio is indeed something I directly installed (through portage), however qtsql and DBD-mysql are dependencies of some tree of dependencies culminating in rstudio, qutebrowser, retext and zeal (packages also installed through portage).

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?". equery query revdeps can complement equo preservedlibs list -v but requires a few manual iterations.

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):

# equo preservedlibs why
/usr/lib64/libmysqlclient.so.18 - needed by:
 -> dev-qt/qtsql-5.9.4 - needed by:
    -> dev-qt/qtwebkit-5.9.1 - needed by:
       -> sci-mathematics/rstudio-1.1.383 - *in world - user installed*
       -> app-doc/zeal-0.3.1 - *in world - user installed*
       -> ...
    -> dev-python/PyQt5-5.10 - needed by:
       -> app-editors/retext-7.0.1 - *in world - user installed*
       -> www-client/qutebrowser-9999 - *in world - user installed*
       -> ...
    -> app-doc/zeal-0.3.1 - *in world - user installed*

@Enlik
Copy link
Member

Enlik commented Apr 18, 2018

Let's split it up.

  • Making -v default: possible, feel free to open a new issue.
  • Showing the revdep tree to identify the cause. Correct me if I'm wrong, but I think the scenario where it would help is that: you update some lib using Portage, it's later updated with Entropy which (hopefully) saves the old library version.
    The thing is, someone who updates non-leaf packages should be careful already and by able to solve problems that may arise though this. Sure, the PM can and should help, but equo q list installed spm-db could be enough to answer "is it me?". What do you think?
  • There is a problem with identification of packages installed by user and as deps, which you also mention. An improvement was recently merged (issue [entropy.client] fix install_sources saving #36), just not tagged yet, but what remains unsolved is that it doesn't read Portage's world file for this in case of packages compiled using that.

@unode
Copy link
Author

unode commented Apr 18, 2018

With regards to the second point, I reached equo preservedlibs after some output seen during update/upgrade. This output highlights libs.
My point is that, unless you are an advanced user with deep knowledge of several packages on the system, you will most likely:

  1. not care - in which case that output will be ignored.
  2. care - in which case answering why those libs were preserved is probably what you will be looking for next.

Makes me wonder if showing:

Some packages (installed through Portage) are causing libs to be kept on the system.
Use `equo preservedlibs list -v` to know more.

instead of the output of equo preservedlibs list as part of equo upgrade is more user friendly and addresses both points. A caring user will know what to do next.

The third point is perhaps the major feature which would make sense under equo preservedlibs why.
This is very much in the 'desireable' category so treat it with a grain of salt. Mostly on making for a better user experience when querying equo.

@Enlik
Copy link
Member

Enlik commented Apr 18, 2018

I was thinking about something you mentioned, although in a simpler form. Something like:

Some packages are causing libs to be kept on the system.
Use `equo preservedlibs list -v` to know more.

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:

  1. Compare with Portage. With its preserved libs feature, it doesn't prove this information directly either.
  2. This is probably because it was though as a way "you have a certain package, it's broken, it can be rebuilt."
  3. And normally that's being done, but if someone thinks the broken package may not be needed anyway, manual investigation of revdeps or simply a depclean can be done.
  4. In Entropy, there is a rough equivalent of depclean, i.e. equo unused [--spm-wanted] which could be used too (it'll be more useful after a version with the above mentioned change is tagged).
  5. I doubt about real (and frequent) cases when someone wants to have deeper investigation and not "just rebuild this damn thing."
  6. If it happens though, Entropy provides or should provide the needed tools to do it in a reasonably convenient way but not implement it directly, something like:
# 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)
where for (other ways can be possible, these are examples) a) equo match -v $p can be used, b) ?, c) equo query revdeps $pkg.

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").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants