This is what I like better about dnf/rpm as the similar location to this for fedora or rhel would be /var/lib/rpm where the db of rpm informations gets stored. If the db there gets corrupted or something like this you just have command that rebuilds this information.
It would be very helpful if there was a single command in debian systems to restore the
/var/lib/dpkg/info files, like the "--rebuilddb" option for dnf, but the files in the rpm database and those in /var/lib/dpkg/info, are to some significant degree, not the same sort of files. The files in a debian system function to some degree in a different way than occurs in fedora.
Briefly, without much recent experience in fedora, I think the database basically holds metadata about packages, package file lists, history of package installation, upgrade, removal ... those sorts of things, stored in a binary database format.
In debian, there is a more extensive listing of basically text files which includes the following sorts:
Code:
Plain text list of all files installed by that package (full paths).
MD5 checksums of the package’s files.
List of configuration files provided by the package (usually under /etc).
Maintenance executable scripts for packages such as:
<pkgname>.preinst - run before installation/upgrade.
<pkgname>.postinst - run after installation/upgrade (e.g., update caches, start services).
<pkgname>.prerm - run before removal.
<pkgname>.postrm - run after removal (cleanup, purge actions).
<pkgname>.config - used by dpkg-reconfigure for interactive reconfiguration.
Control/metadata files (depending on the package):
<pkgname>.triggers
<pkgname>.shlibs
<pkgname>.symbols
<pkgname>.emacsen, etc.
There are also a few global files in the same directory, such as: format, which describes the dpkg info directory format version, and md5sums (sometimes) and overall checksums for some dpkg metadata.
The above variety of files in debian can be seen by navigating to /var/lib/dpkg/info and listing the files. The /var/lib/dpkg/info directory holds a lot of diverse files that dpkg uses, and they are largely human readable as text files with scripts or text info and each has a singular separate function. In fedora, the rpm database is largely in a singular binary database format which is not directly readable, and doesn't cover identical ground.
The above differences are reflected in design differences between dpkg & apt compared with rpm & dnf. The apt commands are a family of commands, each of which has it's own separate functionality
Code:
apt apt-file aptitude-doc-nl apt-offline-gui
apt-cacher apt-forktracer aptitude-doc-ru apt-rdepends
apt-cacher-ng apticron aptitude-robot apt-show-source
apt-config-auto-update apticron-systemd apt-listbugs apt-show-versions
apt-config-icons aptitude apt-listchanges apt-src
apt-config-icons-hidpi aptitude-common apt-listdifferences apt-suggest-auto
apt-config-icons-large aptitude-doc-cs aptly apt-transport-https
apt-config-icons-large-hidpi aptitude-doc-en aptly-api apt-transport-oci
apt-cudf aptitude-doc-es aptly-publisher apt-transport-s3
apt-dater aptitude-doc-fi apt-mirror apt-transport-tor
apt-dater-host aptitude-doc-fr apt-mirror2 apt-utils
apt-doc aptitude-doc-it apt-move apt-venv
apt-eatmydata aptitude-doc-ja apt-offline apt-xapian
The dnf command is more of a singular command that covers its ground by way of sub-commands and options, but is not as extensive as the apt family.
After all of the above, for the original issue, it's clear that the /var/lib/dpkg/info files are vital for proper dpkg functioning on a debian system, so the restoration of the files is really necessary for the system to run as intended.
