1

If I have removed an app with synaptic, (one I have installed with terminal, using the command dpkg -i), why is it removed from the menu (app icon disappears) but still there is the complete folder with all files on the HDD?

I'm not sure why I cannot simply remove the entire folder like you would do in OSX. What happens after using the dpkg -r / -P command with terminal or which synaptic also does?

Is there some reason why I should not just remove the folder(s) manually?

Can somebody explain what is going on behind the scenes, so that beginners like me can understand what they are doing (wrong)?

Update

I tried to uninstall ethereum with the dpkg -r command and it wasn't working (wrong name)??

So I assume that the uninstallation of the ethereum app with Synaptic was good. Synaptic found it and then removed it. I also believe that all relevant data was removed too.

The hidden folder of ethereum that is still on my HDD now, I think is only the data already downloaded, so the app can separately be updated without loosing the blockchain and the wallet-data, right? I think I can delete these files now manually, because I don’t need them anymore!

Zanna
  • 70,465
  • 1
    when you say "there is the complete folder" still remaining, where are you looking? Removing an application with dpkg or synaptic (afaik) does delete files, just not the configuration files in the home directory. Please tell us what app(s) you are talking about and where the remaining files are. A screenshot from the file browser or ls output would help – Zanna Aug 06 '17 at 08:48
  • @Zanna i just not good in english. where are the apps installed? i can't find a bin folder... also is this hidden folder a user data only? its in my home directory – stevethemechanic Aug 06 '17 at 09:06
  • @ Zanna i try to update my post, so you may can better understand what i try to achive... – stevethemechanic Aug 06 '17 at 09:08
  • Typically when you install an application its files are placed by the installation utility in multiple filesystem locations. The executable that is run when you launch the program (and/or a symlink to it) is usually put into /usr/bin or /usr/local/bin and shared library files and documentation are placed in other directories. Typically these filesystem locations are owned by root and not intended to be written to by human users - we don't touch them. Configuration files are saved in users' home directories to allow local settings. These aren't deleted on uninstall, unlike other files. – Zanna Aug 06 '17 at 09:14
  • @Zanna Then - if i do search for every file from that application and delete these manually would be the same, as i execute a commad in the terminal to uninstall it??? It's just a packet on the disk, no registry-files like in that legacy os invilved in all these linux-distros, right?? – stevethemechanic Aug 06 '17 at 10:11
  • to find all the files, in the first place, is in most cases non-trivial. It's much easier to let the package manager find them. But even if you were to find them and delete them all, that could well cause problems. The packaging system has detailed records of what packages are installed and the relationships of dependency between them, and scripts which are run when you uninstall. If you remove a package that other packages depend on without the database being updated, chaos and brokenness will follow! If this is what you wanted to know, then I or someone else can write an answer... – Zanna Aug 06 '17 at 10:46
  • ... in general terms, but it would probably be a duplicate question. But, since you mention files remaining in the system, and installation via dpkg -i, you may be talking about an edge case. Sometimes packages can be installed only locally, not globally, and local config files are not stored in the same place/way for every package. So, I am waiting for you to update your question with specific details, because at the moment the question is a little unclear/broad and I'm not sure what files you're talking about or exactly what you want to know – Zanna Aug 06 '17 at 10:49
  • 1
    @Zanna the 3-third Comment of you is exact what i wantet to know. I will update my question to understand your 4-third Comment right. Give me some time, i'm not a native english speaking... so allways hard work for me to writing questions like these ones ;) – stevethemechanic Aug 06 '17 at 11:03
  • @Zanna I have added some more infos, if you can take a quick look at it, i would be glad. thanks – stevethemechanic Aug 07 '17 at 15:36
  • I'm away from my machine, but I will try to write you an answer soon. Please ping me again if you are still waiting in 48 hours (someone else may answer of course). To be clear, is ethereum the application you were talking about when you first wrote your question? How did you install it? – Zanna Aug 07 '17 at 17:09
  • @Zanna Yes indeed! Ethereum-Wallet (full-node). I have downloaded the deb. file from the website and then dpkg -i. The App was not available in Ubuntus Packet-Manager. Thats why i also have tryed to remove it myself with dpkg -P, but i think now i should have simply to try with only the App-Name (Probably i have used Something like ethereum.deb) – stevethemechanic Aug 07 '17 at 18:24
  • @Zanna ...Because the Packet-Manager has found it, i have removed the App with it. Installing Apps in Ubuntu (to be exact, it's Lubuntu), as a Unix-Beginner i feel a bit overwhelmed with all the dependencys that come allong with an App-Install – stevethemechanic Aug 07 '17 at 18:35
  • Ok, thank you for explaining thoroughly! I think I understand properly now what you are asking about :) I'll try to write an answer for you on Wednesday morning when I get home, but you might receive a better answer in the meantime – Zanna Aug 07 '17 at 18:41

1 Answers1

0

Here's some information from man dpkg, which explains what dpkg -r and dpkg -P do. Removing a package with APT commands or synaptic involves the same procedures; as far as I know high-level package management utilities like APT and synaptic simply call DPKG as a subprocess to remove or install files. Their function is to calculate and resolve dependencies and provide an improved UI.

-r, --remove package...|-a|--pending
          Remove  an  installed  package. This removes everything except conffiles,
          which may avoid having to reconfigure the package if it is reinstalled 
          later (conffiles are configuration files that are listed in the 
          DEBIAN/conffiles control file)[...]
       Removing of a package consists of the following steps:
          1. Run prerm script
          2. Remove the installed files
          3. Run postrm script

-P, --purge package...|-a|--pending
          Purge an installed or already removed package. This removes everything, 
          including conffiles. [...]

          Note: some configuration files might be unknown to dpkg because 
          they are created and handled separately through the  configuration
          scripts. In that case, dpkg won't remove them by itself, but the 
          package's postrm script (which is called by dpkg), has to take care
          of their removal during purge. Of course, this only applies to files 
          in system directories, not configuration files written to individual 
          users' home directories.
     Purging of a package consists of the following steps:
          1. Remove the package, if not already removed.
          2. Run postrm script.

As you can see, these commands delete all of the application's files with the exception of configuration files. Even -P / --purge may not always remove local configuration files from users' home directories in some cases, so these files may need to be deleted by hand if they are no longer needed. When you mention application directories remaining after uninstallation, you are most likely talking about a local config directory.*

In my answer to a somewhat related question I discussed how APT, DPKG and other package managers installed on an Ubuntu system store information about the files provided by a package in a human-readable form.

That answer also tries to explain why using a package manager to handle package management is substantially easier than trying to do so by hand; in a typical Linux filesystem, files provided by applications are scattered all over the place. While this might seem confusing, there's a great security advantage to application files being in system directories owned by root that users cannot write to. Besides, if we do need to find out where files related to a package are, we can use various command line utilities to find them.

You wanted to know whether deleting all of the files of an application to uninstall it is a bad idea and if so why. My answer to this question is YES, in general it's a very bad idea, because deleting the installed files is only part of the work done by package management when you call it to perform an uninstallation. The DPKG database stores information on which packages are installed and installable, and all the relationships of dependency between them. If package files are removed without the database being updated, then dependency resolution won't be done, software that depends on silently missing software will fail to run, packages will be broken, the cleanup done by prerm and postrm scripts dpkg calls for each package it removes will not be done, potentially leaving broken symlinks and incorrect config files lying around, and everything will be horrible.

TL;DR
Package managers exist for good reasons. Use them where possible rather than trying to do-it-yourself.

*However, sometimes software may be installed (and have a single directory) without DPKG knowing anything about it. For example, you may download a 3rd party application, extract the archive and run the executable file. To "uninstall" this software, you can simply delete the extracted files. Another example is installation using sudo make install after compilation from source, which leaves the source directory behind. Uninstalling such software can be a headache if the developers have not configured things so as to enable sudo make uninstall or not included a file manifest! A way around this is to create a deb package after make, which can be done with checkinstall.

Zanna
  • 70,465