[pacman-dev] Inconsistent output when db.lck present

[Nagy Gabor]

> For example:
> 
> allan at mugen ~
>  > sudo touch /var/lib/pacman/db.lck
> Password:
> 
> allan at mugen ~
>  > pacman -Syu
> :: Synchronizing package databases...
> error: failed to update allanbrokeit (unable to lock database)
> error: failed to update kernel64 (unable to lock database)
> error: failed to update testing (unable to lock database)
> error: failed to update core (unable to lock database)
> error: failed to update extra (unable to lock database)
> error: failed to update community-testing (unable to lock database)
> error: failed to update community (unable to lock database)
> error: failed to synchronize any databases
> 
> allan at mugen ~
>  > pacman -U 
> /var/abs/local/pacman-git/pacman-git-20110828-1-i686.pkg.tar.xz
> error: failed to init transaction (unable to lock database)
>    if you're sure a package manager is not already
>    running, you can remove /var/lib/pacman/db.lck
> 
> 
> Allan
> 

Well, in fact "pacman -Su" is consistent with "pacman -U". Here the
inconsistency is between "pacman -Sy" and "pacman -U", because -Sy is
not a transaction, and alpm locks/unlocks the database in every
alpm_db_update() call, and all attempts fail in this case. I don't see
any clean solution to this: We can "predict" that all database update
will fail (which is theoretically not always true, but it has very high
probability) and do some hackish things, or modify alpm_db_update's
parameters to get an alpm_list of databases, but then the error
handling would be more complicated.

If consistency is so important, we could implement a check_db_lock
stuff similar to our needs_root()/check_root stuff (I guess this needs
alpm work too), and pacman could do this check before doing anything
(if it is necessary, which can be calculated from command-line
arguments). [But of course, alpm db-lock check should be also kept in
this case. This would be just an extra check, called from front-end.]

But I am fine with the current output.

NG