Way to reproduce: Open synaptic, use root password. Find some package (for example libgmp-devel) and check for install (!!!) In konsole execute: $sudo apt-get install something (i tried virt-viewer) Same for $apt-get remove First package will be installed, and then apt-get stops. apt-get do not respond on ^z and ^c. apt-get will resume if synaptic will be closed. But if user forget about synaptic and kill apt-get(by kill -9 or closing konsole window) system may stay in unstable state. With, for example, two versions of same lib installed. Proposal -- check if other PM is running at start of apt-get. Debian, as i remember, does not start apt if synaptic is running. $apt-get --version apt 0.5.15lorg2 для linux x86_64 собран Feb 9 2022 23:33:31 $apt-cache show synaptic Package: synaptic Section: System/Configuration/Packaging Installed Size: 5094531 Maintainer: Ivan Zakharyaschev <imz@altlinux.org> Version: 0.58-alt28:p10+295130.700.2.1@1644479727
Thanks for the report! (I hope someone some day will think about it and implement a solution.) A few more lock-related observations: * Now, concurrent install/remove actions can lead to broken state at the end -- https://bugzilla.altlinux.org/40348 * Waiting for locks before starting another instance of apt in Debian -- https://unix.stackexchange.com/q/242539/4319
I'm afraid that having just a lock for apt wouldn't solve a potential race between plain rpm and apt-or-whatever, as described in https://bugzilla.altlinux.org/40348 ; if a more tricky locking scheme is implemented in rpm (like the one suggested there), that would make "apt-get install" (or "rpm -U") at least not start the installation as long as synaptic holds a read-lock on the database. (Probably, that is the reason for the described behavior, but I might be wrong.)
