1

In a foolhardy and stupid attempt to solve space issues on my desktop machine, I on purpose deleted Spotify from /opt before realizing that I could remove it using the package manager. After deleting the folder I tried to purge Spotify using aptitude but deleting the files in /opt had broken the package manager because of the expected but missing directories and files.

I managed to solve this problem by manually changing aptitudes files, purge Spotify and reinstall using aptitude without having to reinstall the whole system. Now I am worried that there is still "something" left that might not be OK after I manually made changes although everything seems to be fine.

Questions: Are there any databases or flat files being held by aptitude or dpkg where I can run a consistency check against it and the installed packages to see that they correlate and are OK?

Does the mentioned software (dpkg, aptitude, apt-*) have mechanisms to do this for me? I can not see any in the manuals but thought I would ask here in case someone know a way.

cheers.

Improve this question

1 Answer 1

Reset to default
2

You can see almost1 all the files of an installed package by running

dpkg -L thatpackage

Or this same information is available on http://packages.debian.org — you pick a package in the required distribution, then on that package's page navigate the "list of files" link in a table row matching your hardware architecture.

Another package which might be of interest for you is debsums which is able to compare the files belonging to a package or a set of packages, as found on the filesystem, with their MD5 hash sums as recorded in the metadata of the packages. The intended usage is detection of tampering with the system files, but might be used in your case as well, I think.

1 Some packages create certain files and directories dynamically, and unfortunately this is not declarative: they do so using plain shell scripting in the so-called postinst and postrm scripts, which are called by the package manager when certain events happen in the package's lifetime. For instance, a package might generate its configuration file using ucf from a privately-kept template using the information obtained from the user during the package configuration phase, and install the generated file somewhere under the /etc hierarchy.

These "plumbing" scripts belonging to a package are kept under the /var/lib/dpkg/info hierarchy and have names matching the packagename.* pattern. By the way, the lists of the files installed by a package and the list of configuration files maintained by the package are kept under the same hierarchy in the files named like packagename.list and packagename.conffiles. This is an implementation detail (better use dpkg -L or similar devices) but still…

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .