Results 1 to 7 of 7

Thread: Tracing back why a package is installed

  1. #1

    Default Tracing back why a package is installed

    This is partially an academic question but partially practical as well. I'm trying to "slim down" my KDE install and I want to check why certain packages are installed so that I make sure that I'm not removing something that may provide additional functionality. I've hit a dead end with two packages, akonadi-server and kaccounts-integration. I do understand what these packages are, but from a package management perspective I cannot figure out what requires/recommends them that caused them to be installed. I installed Tumbleweed and removed some packages from the default KDE install (akregator, kaddressbook, kmail, kontact, konversation, kopete, korganizer, plasma5-pk-updates). I know that kaccounts-integration is its own application, so it would not tie into this, but I thought that I removed everything that should rely on akonadi.

    I've taken a few steps to try to trace this back. First, I checked what would be removed if I ran
    Code:
    zypper rm --clean-deps (package name)
    . I then checked the install status for all of the packages that would be removed and they were all (including akonadi-server and kaccounts-integration themselves) installed automatically. I then tried to trace the package requirements with
    Code:
    zypper se --requires --recommends --suggests
    on each of the packages, but I end up stuck in a loop where they all just seem to recommend or require themselves and no other packages.

    Any suggestions as to further steps to determine what requires or recommends these packages? I think it may be something related to patterns but I haven't been able to find a pattern that would install those packages.

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,354
    Blog Entries
    3

    Default Re: Tracing back why a package is installed

    I would just go into Yast software management. And then mark the package to be removed.

    I would expect a "conflict resolution" window to pop up, telling me everything else that it wants to remove. I can make experimental choices there, and see what else pops up. And I can abort the whole session without actually changing anything.

    You will probably find that akonadi is integrated into KDE in a way that it cannot be easily removed.
    openSUSE Leap 15.1; KDE Plasma 5;

  3. #3
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    26,500
    Blog Entries
    15

    Default Re: Tracing back why a package is installed

    Hi
    Perhaps the kaccounts-integration-lang package?

    There are lots of requires...
    https://build.opensuse.org/package/b...itory=standard
    Last edited by malcolmlewis; 14-Jun-2017 at 13:40.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  4. #4
    Join Date
    Jun 2008
    Location
    Groningen, Netherlands
    Posts
    19,649
    Blog Entries
    14

    Default Re: Tracing back why a package is installed

    Remove the KDE/plasma related *pattern* packages. But, I don't understand the reasoning. Why would you want to remove packages that you ( in the installer ) chose to install? Who/what are these packages hurting / interfering with?
    ° Appreciate my reply? Click the star and let me know why.

    ° Perfection is not gonna happen. No way.

    https://en.opensuse.org/openSUSE:Board#Members
    http://en.opensuse.org/User:Knurpht
    http://nl.opensuse.org/Gebruiker:Knurpht

  5. #5

    Default Re: Tracing back why a package is installed

    Quote Originally Posted by nrickert View Post
    I would just go into Yast software management. And then mark the package to be removed.

    I would expect a "conflict resolution" window to pop up, telling me everything else that it wants to remove. I can make experimental choices there, and see what else pops up. And I can abort the whole session without actually changing anything.

    You will probably find that akonadi is integrated into KDE in a way that it cannot be easily removed.
    That's what I expected, but I can remove akonadi-server without any other packages being removed. It concerns me though because even if I re-install kmail, which I know uses akonadi for storage, I can remove akonadi-server without it prompting me to remove kmail.

    Quote Originally Posted by malcolmlewis View Post
    Hi
    Perhaps the kaccounts-integration-lang package?

    There are lots of requires...
    https://build.opensuse.org/package/b...itory=standard
    kaccounts-integration-lang isn't installed... The only reverse dependencies I can find (by using zypper se --requires --recommends --suggests) are kaccounts-integration-lang, which is not installed, and libkaccounts1, which is installed automatically but is not required by any packages I have installed.

    Quote Originally Posted by Knurpht View Post
    Remove the KDE/plasma related *pattern* packages. But, I don't understand the reasoning. Why would you want to remove packages that you ( in the installer ) chose to install? Who/what are these packages hurting / interfering with?
    That's the problem, to my knowledge I did not choose to install them and I'm trying to figure out what other package I selected that caused them to be installed. If I remove the kde and kde_plasma patterns and the akonadi-server package, then do a zypper dup, the system wants to install akonadi-server again.

    And honestly, if I can't figure it out I'll just leave them, but I'd like to know how to find out why a given package was installed...

  6. #6
    Join Date
    Jun 2008
    Location
    Groningen, Netherlands
    Posts
    19,649
    Blog Entries
    14

    Default Re: Tracing back why a package is installed

    My guess is you still have some akonadi related packages installed.
    Could you check
    Code:
    rpm -qa | grep -i akonadi
    If so ( libs whatever ), remove them.
    ° Appreciate my reply? Click the star and let me know why.

    ° Perfection is not gonna happen. No way.

    https://en.opensuse.org/openSUSE:Board#Members
    http://en.opensuse.org/User:Knurpht
    http://nl.opensuse.org/Gebruiker:Knurpht

  7. #7

    Default Re: Tracing back why a package is installed

    Quote Originally Posted by Knurpht View Post
    My guess is you still have some akonadi related packages installed.
    Could you check
    Code:
    rpm -qa | grep -i akonadi
    If so ( libs whatever ), remove them.
    Thank you, but I do know how I could remove akonadi if I decided to. My question is really what I had in the original post: I'd like to figure out why it's installed (what pattern or package caused it to be automatically installed) before I decide if I want to remove it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •