FS#9609 - -Sc prompts to delete db.lck file
Attached to Project:
Pacman
Opened by Scott H (stonecrest) - Tuesday, 19 February 2008, 00:34 GMT
Last edited by Dan McGee (toofishes) - Tuesday, 26 February 2008, 03:54 GMT
Opened by Scott H (stonecrest) - Tuesday, 19 February 2008, 00:34 GMT
Last edited by Dan McGee (toofishes) - Tuesday, 26 February 2008, 03:54 GMT
|
Details
Run a -Syu in one pacman instance, then call -Sc in another.
It'll give you the following:
$ pacman -Sc <snip> Do you want to remove unused repositories? [Y/n] Do you want to remove /var/lib/pacman/db.lck? [Y/n] It's probably worth having pacman not prompt the user about the db.lck file. (FWIW, I did this because I was installing openoffice-base-devel from unstable and just realized I might not have enough space.) |
This task depends upon
Closed by Dan McGee (toofishes)
Tuesday, 26 February 2008, 03:54 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in 3.1.2, see commit 7879e4bef7c158814a547d232f0bde8960ee1341
Tuesday, 26 February 2008, 03:54 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in 3.1.2, see commit 7879e4bef7c158814a547d232f0bde8960ee1341
I had the md5sum not pass for OOo, perhaps that's why.
$ sudo pacman -Sc
Cache directory: /var/cache/pacman/pkg/
Do you want to remove uninstalled packages from cache? [Y/n] n
Database directory: /var/lib/pacman/
Do you want to remove unused repositories? [Y/n] y
Do you want to remove /var/lib/pacman/foo.bar? [Y/n] n
Database directory cleaned up
Looks like our friend alpm_option_get_syncdbs() is stupid. That should solve part of the problem, the other is requiring this cache clean to require a lock.
EDIT: scratch the above line, I can't read the code. However, I should be able to come up with a fix for this.
Now about the package clean part, yes, -Sc would have deleted everything you had just downloaded. All the first targets that were fully downloaded but not yet installed.
But even the one currently downloading will still look fine to pacman, because it only do a quick load of the archive (basically only reading .PKGINFO), instead of trying to
read the whole archive which really hurts the performance. And it will see that this package is not yet installed and should delete it too.
About locking the database for -Sc:
Do we need a public function in the backend as Nagy suggested, to allow the frontend to lock / unlock the database?
Because we have the same problem for -Sy and -Sc : both are not real transactions (no trans_addtarget, trans_prepare, trans_commit stuff),
but both require to lock the database.
We could do like I did with -Sy here : http://www.archlinux.org/pipermail/pacman-dev/2008-February/011201.html
I call trans_init and trans_release only for locking and unlocking the database. But I am not sure it's very nice :/
Maybe we should move these operations in the backend then, and implement them as real transactions (-Sy is already mostly in the backend, but -Sc is all in the frontend).
Or it might be better to just export lock / unlock functions. I have no idea..
So I'll trust Dan's judgment.
Regarding the other stuff, I think we need a trans_init and trans_release that are lighter weight- in essence, true transaction operators. We'll worry about that for 3.2 though, and do the short-term fix for now for 3.1.2.
Anyway, that's a corner case, so not a big problem.
And so, what is the short-term fix? Using sync_trans_init and sync_trans_release like in my -Sy patch?
Can my -Sy patch be applied then ? Or only the part that contains these two functions?