[pacman-dev] pacman locking the db when downloading with -S ?
i found this strange behavior: while i had pacman3 -Syu downloading some updates it kept the db locked so makepkg3 couldn't check the deps. [andyrtr@workstation64 pacman3]$ rm -rf src/ && time makepkg3 -L ==> Entering fakeroot environment ==> Making package: pacman-rc 2007.02.25-1 (So 25. Feb 14:34:46 CET 2007) ==> Checking Runtime Dependencies... Fehler: unable to lock database ==> ERROR: pacman3 returned a fatal error (1): Wenn Sie sicher sind, dass nicht bereits ein Paketmanager gestartet ist, können Sie /tmp/pacman.lck entfernen ==> Checking Buildtime Dependencies... Fehler: unable to lock database ==> ERROR: pacman3 returned a fatal error (1): Wenn Sie sicher sind, dass nicht bereits ein Paketmanager gestartet ist, können Sie /tmp/pacman.lck entfernen ==> Retrieving Sources... ==> Validating source files with md5sums ==> Validating source files with sha1sums ==> Extracting Sources... It's ok that the pacman -Syu job locks the db while checking the dependencies but it should unlock them after that immediatly and maybe relock when installing the packages. Andy
Am Sonntag, 25. Februar 2007 14:40:13 schrieb Andreas Radke:
It's ok that the pacman -Syu job locks the db while checking the dependencies but it should unlock them after that immediatly and maybe relock when installing the packages.
This could be solved by introducing two different locks: read-only and exclusive. -- http://www.archlinux.de
On 2/25/07, Andreas Radke <a.radke@arcor.de> wrote:
i found this strange behavior:
while i had pacman3 -Syu downloading some updates it kept the db locked so makepkg3 couldn't check the deps.
Actually, that's a little reversed. The problem is that dep checking shouldn't require a DB lock. I am looking at this tonight, so don't fear.
On 2/25/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 2/25/07, Andreas Radke <a.radke@arcor.de> wrote:
i found this strange behavior:
while i had pacman3 -Syu downloading some updates it kept the db locked so makepkg3 couldn't check the deps.
Actually, that's a little reversed. The problem is that dep checking shouldn't require a DB lock. I am looking at this tonight, so don't fear.
This is fixed in CVS now
participants (3)
-
Aaron Griffin
-
Andreas Radke
-
Pierre Schmitz