How to get rid of redundant packages?

[MrAccident]

Bionic-Pup-64
I've tried a bunch of programs ― and when uninstalling them - PPM keeps their dependencies; and there's a shitload of them now! And no idea ― which belongs to which program.
Is there something like - Check Dependencies ― but in reverse?

[perdido]

Hi MrAccident,

Were these extra dependencies from packages added with the Puppy Package Manager?
Dependencies added with a package (like .deb or .pet) should be uninstalled when the package is removed by PPM

PPM removes only the original files that were in the package and not additional files created by the program or user when running the program.
Those are often left in /root/ and /root/.config/ after a package is removed but many programs leave files in other directories.

Puppy keeps the user-installed packages listed in /root/.packages/ - sometimes worth snooping around there if you don't see packages in the PPM that you know you added but are not showing.

Have fun!

[MrAccident]

@perdido - they were added by PPM. Now they are in PPM; I see them after clicking "Uninstall" button.
I'm pretty sure that it doesn't remove them. Maybe I should always choose "Step by step remove" instead of "Auto remove"?
Anyway - what do I do now?

[perdido]

@perdido - they were added by PPM. Now they are in PPM; I see them after clicking "Uninstall" button.
I'm pretty sure that it doesn't remove them. Maybe I should always choose "Step by step remove" instead of "Auto remove"?
Anyway - what do I do now?

Hi MrAccident,

Does the PPM show an error when you try to uninstall one of those packages?

The installed user packages are listed in the file /root/.packages/user-installed-packages
If the package refuses to uninstall it could be the file that is associated with the installed package you are trying to remove is damaged or missing.

In /root/.packages/ directory there will be files ending with the extension .files - those are listing the files included with an installed package. For each installed package shown in user-installed-packages there should be a .files file.

You can compare what is included in the user-installed-packages file against what is included in the /root/.packages/ directory , there should be a .files file for every package listed in the user-installed-packages file list.

If the .files file is missing for an associated package then the PPM will not uninstall the package listed in user-installed-packages.
That is only a guess of what could be the issue.

Have fun!

[MrAccident]

@perdido - I meant that I don't know what packages in PPM are for; so I don't know which to uninstall. Otherwise - there wouldn't be a problem. I just want to get rid of redundant ones.

[tallboy]

MrAccident, I know excatly what you mean! Extremely annoying! I try to remember to only download - not install - those packages that I want to try, along with their deps, and then install them from the Downloads folder. If I test run such a package, and decide to remove it again, I use the ppm to remove the installed files. I still have the downloaded files, so I can see the names of all the deps. I then use pFind to search for any files containing the names of the dowloaded files. I usually find some dot-files here and there, containing prefs that were made during test run, but never used.
If you are good with the 'find' command, you may also set up a search for files made after a certain time, and delete them all.
I miss having a good, recent Puppy on a multisession disc, then you just reboot the disc and every temporary files are gone...

[MrAccident]

@tallboy - that's a big problem in Puppy. I hope it will be solved in the future.
It's a good thing that I'm still on my quite old computer, and I want to buy a new one; so I will have to start from scratch.
In the mean while - I think a good idea is to take a picture of the region of the installed program + it's dependencies, after an installation.

[01101001b]

I meant that I don't know what packages in PPM are for; so I don't know which to uninstall. Otherwise - there wouldn't be a problem. I just want to get rid of redundant ones.

Maybe I'm wrong but I think I get what you mean.
Not a solution, but I have always uninstalled apps in PPM this way:

First, let's say I install an app named A-app. After installation, I see something like this in PPM (in the "installed packages" list, to the left):

(dependency)
(dependency)
(dependency)
A-app

Later, let's say I decided to install one more app (B-app). After installation, I'll see something like this (in PPM):

(dependency)
(dependency)
(dependency)
A-app
(dependency)
B-app

Now, let's assume one last installation:

(dependency)
(dependency)
(dependency)
A-app
(dependency)
B-app
C-app

And NOW we uninstall B-app (but wait! Don't select B-app only. Select B-app and all "(dependency)" between B-app and the previous app (A-app in this example) (You'll need to know how to select using Control key + click or Shift key).
Then, uninstall.

If done right, you will see in the installed apps list in PPM:

(dependency)
(dependency)
(dependency)
A-app
C-app

This is the only way I know to keep your system as slim as possible. Very rarely you will uninstall a dependency needed by a less recent installed app (if that's the case, just run the failing app from console and you will discover the missing dependency. Install it and problem solved).

Obviously this is far from perfect and you might prefer some "cooler" way to uninstall but it works pretty fine for me (in DPupBuster).

Hope it helps.

PS: If you caught the IDEA behind this explanation, you'll be able to get rid of superfluous, now unneeded, dependencies from your system quite easily, perhaps with no trouble at all. Good luck!

[MrAccident]

@01101001b - thanks; but I already was doing it like that. But then - I reinstalled something, or something like that ― and that scrambled the order; and I was trying a bunch of programs; and now it's a mess.

[tallboy]

Another problem is that a dependency may also be used by another program that you actually want to keep...
I think the method I described is the closest you can get, to order in the ppm.

[O.F.I.N.S.I.S.]

@01101001b - thanks; but I already was doing it like that. But then - I reinstalled something, or something like that ― and that scrambled the order; and I was trying a bunch of programs; and now it's a mess.

That's one reason why I prefer to use .sfs modules. If I want a program to use or just to test, I download the program plus all its dependencies. After everything is downloaded I create a directory (named after the program, but different to the downloaded .deb or whatever file's name) inside my programs collection directory and move all the files into that directory.

Then I right-click this created directory containing all downloaded program/dependencies files and choose: "Combine to SFS". This is a right-click tool to create .sfs modules from different archives and packages stored inside a directory.

You can find this tool somewhere in the Utilities section of the forum. I wrote this tool some time ago and it's called "PaDS". Ok, found it: http://murga-linux.com/puppy/viewtopic.php?t=113888

Using .sfs modules is simple, easy and pretty smart, as it will keep your Puppy slim and healthy, since nothing is going to be installed. Those .sfs modules can be loaded when wanted to use its included program and unloaded after finishing the work.

[tallboy]

Hallo, Reiner. Will not some .SFS packages place a dot-file with preferences in, for example, /root? And that will not be removed when you close the SFS.

[O.F.I.N.S.I.S.]

Hallo, Reiner. Will not some .SFS packages place a dot-file with preferences in, for example, /root? And that will not be removed when you close the SFS.

Yes. Just like installed programs, programs from .sfs also needs to store its settings somewhere. Some in /root, some in /root/.config. But I'm sure: they won't create a mess.

When I was saying "nothing is going to be installed", it (installed) was meant like when installing a .pet or .deb or any different installation package/archive.

[tallboy]

But I'm sure: they won't create a mess.

I can give you an ecample where they - at least in theory, can make a mess: If you frequently use a program from an .sfs, and then make a new .sfs with the latest program version. If there are fundamental differences in the settings in a prefs file, and the new prefs file has the same name as the old prefs file, you may have some problems, even if you have not made any entries in the prefs files, or even know that it exists. As I said, in theory!