When a system has both RPM and DPKG we have a fallback that attempts to determine the main format. This works by looking at local metadata files for the installed packages on the system. * Our DPKG code checks: /var/lib/dpkg/status * Our RPM code checks: /var/lib/rpm/Packages However, /var/lib/rpm/Packages is only present if RPM is using the backend called "BDB". According to this page there are 3 available backends that can be used: https://rpm.org/user_doc/db_recovery.html It seems we need to look at different files for different backends. A common scenario where both RPM and DPKG are installed is if the software "alien" is installed. Since the fallback fails for RPM, the problematic scenario is if RPM is your main package format, you are using a backend other than BDB, and you have installed alien. Our code will then detect that both formats are available and attempt to use our fallback. The fallback will fail to find /var/lib/rpm/Packages (since this info is instead in /var/lib/rpm/rpmdb.sqlite for example). This results in that we think RPM isn't being used. Depending on how much DPKG has been used on the system (we look at the size of /var/lib/dpkg/status) the result can be one of: * ThinLinc's deb packages are installed instead * the user can't install ThinLinc at all
It seems by default we get the sqlite backend for RPM on Fedora 33. The default on RHEL 8 seems to be BDB.
This command can be used to check which backend your RPM system is using: rpm -E "%{_db_backend}"
According to https://rpm.org/ the BDB backend is deprecated as of rpm-4.16.0.
The backend used by rpm can be changed dynamically by editing the `%_db_backend` macro in `/usr/lib/rpm/macros` followed by running `rpmdb --rebuilddb` to convert the previous database to match the configuration. Meaning that the database format used is not necessarily tied to the distribution. The new default backend for rpm is SQLite (as of commit https://github.com/rpm-software-management/rpm/commit/abb19a23b9386bb14ac38e65f0b6bdc6bd306ada). Just as RHEL8 (as mentioned in comment 1), SLES12 and SLES15 use `bdb`. Looking at openSUSE Tumbleweed, it seems like they choose to diverge from the default upstream rpm configuration as they use `ndb` instead.
For multiple database types to be available for rpm, these must be enabled during the `./configure` step of building rpm. The number of available database backends for the distribution provided rpm varies between distributions: - On Fedora 34, rpm was built with support for both SQLite and ndb. The database can be converted between SQLite and ndb as described in comment 4. - On openSUSE Tumbleweed, rpm was built without support for SQLite. Nonetheless, there are distributions (such as the mentioned Fedora 34) where the database backend can be changed without rebuilding rpm.
An additional issue here is that '/var/lib/rpm' isn't always the path to the database for RPM. After installing alien on Ubuntu 21.04 the path I got was: /home/cendio/.rpmdb The path can be checked using `rpm -E "%{_dbpath}"`, perhaps we can use this in the code?
/home/cendio/.rpmdb would be something user specific, so that can't possibly be the system package manager.
Let's assume that if the RPM db isn't available somewhere under /var/lib/rpm, RPM isn't the main package format on that machine.
This is fixed now. I have tested on Ubuntu 21.04 and RHEL 7 using the software alien in order to get both RPM and DPKG installed at the same time: ✓ RPM is chosen if only RPM is available ✓ RPM is chosen if "/var/lib/dpkg/status" is empty or non-existant ✓ DPKG is chosen if only DPKG is available ✓ DPKG is chosen if RPM database isn't in "/var/lib/rpm/" ✓ DPKG is chosen if "/var/lib/rpm/rpmdb.sqlite" is empty ✓ DPKG is chosen if "/var/lib/rpm/Packages.db" is empty ✓ DPKG is chosen if "/var/lib/rpm/Packages" is empty ✓ No package format is chosen if both the RPM db and DPKG db are 1.8M As described in comment 7, the database path for RPM from alien seems to be "/home/<USER>/.rpmdb". The path can be changed to "/var/lib/rpm/". This path can be changed in "/usr/lib/rpm/macros" and the parameter is called "_dbpath". This has to be followed by a rebuild of the database `sudo rpmdb --rebuilddb`. Note comment 9, users of alien will likely not modify the database path in the real world, it's described here mainly for testing purposes. If RPM from your system, or from alien, is built using the appropriate flags you can switch your current database between different database formats using the method described in comment 4.
Tested the solution on build 2157 on Fedora 33 and Ubuntu 18.04: ✓ RPM is chosen if only RPM is available ✓ RPM is chosen if "/var/lib/dpkg/status" is empty or non-existant ✓ DPKG is chosen if only DPKG is available ✓ DPKG is chosen if RPM database isn't in "/var/lib/rpm/" ✓ DPKG is chosen if "/var/lib/rpm/rpmdb.sqlite" is empty ✓ DPKG is chosen if "/var/lib/rpm/Packages.db" is empty ✓ DPKG is chosen if "/var/lib/rpm/Packages" is empty ✓ No package format is chosen if both the RPM db and DPKG db are the same size ✓ Will result in "Unsupported package format" error in our installer Looks good.