It's expected that if a transaction started and then succeeded, then the resulting state is consistent (in a certain sense; if it wouldn't be consistent with what the user expects, rpm simply wouldn't start the transaction and report errors in the beginning). However, due to lock race, concurrent conflicting transactions can complete and result in an unexpected "inconsistent" state (unmet deps; unowned files perhaps). * * * rpm -U unpacks the pkg into the filesystem without having a write lock. Right after this, another process (like APT) may win the race in acquiring the write lock and modify the DB differently, in an incompatible way, say... ...removing another pkg required by the one being installed by RPM. This kind of race is acknowledged by rpm developers and is confirmed by my example. There can be races when going from read-only access to the DB (when preparing and doing the deps processing) to write access (when performing the transaction), and this may be even unsolved on the level of rpmlib -- https://github.com/rpm-software-management/rpm/blob/992a4f903585cde1ad051b46f89b8b947b1cdae3/lib/rpmts.c#L95 Theoretically, it can't be solved (a guaranteed way to "upgrade" a read-lock to a write-lock), because then there could be a deadlock when two process want to "upgrade" the lock at the same time. A solution could be for rpm to start holding the write lock earlier. That could mean that scriplets wanting to do rpmquery would block. So the next part of a solution could be using a pair of locks: * want write access: acquire exclusively LOCK1, then acquire exclusively LOCK2. * want read access: acquire non-exclusively LOCK2. * drop write access: drop LOCK2, then drop LOCK1. * drop read access: drop LOCK2. * temporarily give up the write lock: drop LOCK2 (then, perhaps, acquire it non-exclusively). * restore write lock: acquire exclusively LOCK2 (perhaps, after first dropping it). So, LOCK1 is a new extra lock, LOCK2 can be treated exactly as the old lock. The "perhaps" actions in parentheses are optional in the new protocol, but are possible to look like the old code (if they are performed, old code and old clients would be in exactly the same situation as they are now). Alternatively, what if we identified LOCK1 with the old lock? Then old clients won't notice us having a read-lock and could start writing. That's bad. (I've also found some related discussion at https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock#Upgradable_RW_lock but not found new useful ideas there though.) How to reproduce: # rpm -q rpm apt --qf='%{NAME}-%{EVR}:%{DISTTAG}\n' rpm-4.13.0.1-alt24:p9+254187.340.9.1 apt-0.5.15lorg2-alt71.3:p9+258439.100.1.1 Choose a big pkg (so that you have time to stop rpm -U) that has a dependency you can easily remove. SCREEN 1 [root@blacky ~]# rpm -e libmozjs78-debuginfo [root@blacky ~]# rpm -Uvh /var/cache/apt/archives/libmozjs78-debuginfo_78.0.1-alt3%3asisyphus+274089.1200.2.1@1623242399_x86%5f64.rpm Preparing... #################################################################################################### [100%] Updating / installing... 1: libmozjs78-debuginfo-78.0.1-alt3 ############^Z [1]+ Stopped rpm -Uvh /var/cache/apt/archives/libmozjs78-debuginfo_78.0.1-alt3%3asisyphus+274089.1200.2.1@1623242399_x86%5f64.rpm # SCREEN 2 (with APT) [root@blacky ~]# apt-get remove libicu69-debuginfo Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED: libicu69-debuginfo 0 upgraded, 0 newly installed, 1 removed and 1316 not upgraded. Need to get 0B of archives. After unpacking 56,3MB disk space will be freed. Do you want to continue? [Y/n] Committing changes... warning: waiting for transaction lock on /var/lib/rpm/.rpm.lock SCREEN 2 (alternatively, with RPM) [root@blacky ~]# rpm -evh libicu69-debuginfo warning: waiting for transaction lock on /var/lib/rpm/.rpm.lock SCREEN 1 [root@blacky ~]# fg rpm -Uvh /var/cache/apt/archives/libmozjs78-debuginfo_78.0.1-alt3%3asisyphus+274089.1200.2.1@1623242399_x86%5f64.rpm ######################################################################################## [100%] Running /usr/lib/rpm/posttrans-filetriggers [root@blacky ~]# SCREEN 2 Preparing... #################################################################################################### [100%] Cleaning up / removing... 1: libicu69-debuginfo-1:6.9.1-alt1 #################################################################################################### [100%] Done. [root@blacky ~]# apt-get check Reading Package Lists... Done Building Dependency Tree... Done You might want to run `install --fix-broken' to correct these. The following packages have unmet dependencies: libmozjs78-debuginfo: Depends: debug64(libicui18n.so.69) Depends: debug64(libicuuc.so.69) E: Unmet dependencies. Try using --fix-broken. [root@blacky ~]# SCREEN 2 (alternatively, with RPM) Preparing... #################################################################################################### [100%] Cleaning up / removing... 1: libicu69-debuginfo-1:6.9.1-alt1 #################################################################################################### [100%] Running /usr/lib/rpm/posttrans-filetriggers [root@blacky ~]# apt-get check Reading Package Lists... Done Building Dependency Tree... Done You might want to run `install --fix-broken' to correct these. The following packages have unmet dependencies: libmozjs78-debuginfo: Depends: debug64(libicui18n.so.69) but it is not installable Depends: debug64(libicuuc.so.69) but it is not installable E: Unmet dependencies. Try using --fix-broken. [root@blacky ~]#
