lock file is not removed at guild update

[ijp]

Reported by Stis on freenode #guile

lock file is not removed at guild update.

A possible solution is to always rm the lock file if we are about to make a new database or supply a clean-lock argumend to guild.

backtrace:
stis@blackbone:~/stis/src/guildhall$ guild clean
Backtrace:
In ice-9/boot-9.scm:
 157: 13 [catch #t #<catch-closure 12ee920> ...]
In unknown file:
   ?: 12 [apply-smob/1 #<catch-closure 12ee920>]
In ice-9/boot-9.scm:
  63: 11 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 414: 10 [eval # #]
In /home/stis/stis/src/guile/meta/guild:
  68: 9 [main ("/home/stis/stis/src/guile/meta/guild" "clean")]
In scripts/clean.scm:
  46: 8 [main]
In guildhall/cli.scm:
  94: 7 [call-with-parsed-options #<directory (scripts clean) 13bfc60> () ...]
In guildhall/cli/db.scm:
  71: 6 [#<procedure 1fd97e0 at guildhall/cli/db.scm:70:4 (args config)> () #]
In ice-9/boot-9.scm:
 171: 5 [with-throw-handler r6rs:exception ...]
In guildhall/database.scm:
 177: 4 [open-database # # # ...]
In ice-9/boot-9.scm:
 102: 3 [#<procedure 1f95100 at ice-9/boot-9.scm:97:6 (thrown-k . args)> r6rs:exception ...]
In unknown file:
   ?: 2 [#<procedure 1fec4e0 (key . args)> r6rs:exception #]
In guildhall/cli/db.scm:
  48: 1 [#<procedure 1fed0f0 at guildhall/cli/db.scm:47:4 (c)> #]
In ice-9/boot-9.scm:
 106: 0 [#<procedure 1f95100 at ice-9/boot-9.scm:97:6 (thrown-k . args)> r6rs:exception ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure 1f95100 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: ERROR: R6RS exception:
  1. &fatal-error
  2. &message: "database locked: /home/stis/.local/var/lib/guildhall/"

[ijp]

The problem isn't so much that guild update doesn't remove the lock, but the command that ran before it didn't. If the commands were to ignore the lock willy-nilly, it would defeat the purpose of a lock in the first place.

Solution, as I see it, is to fix the commands so that locks get released if an exception is raised. If a lock is in place, you should get a nice error message. And maybe add a command for cleaning the lock explicitly, in case it all does go awry.

[NalaGinrut]

yes, the error should get more friendly treatment rather than throw all things plus backtracking directly.
The same issue occurs when a package wasn't found in the repo.

[NalaGinrut]

The database lock issue occurs when I try ctrl+c when it works, maybe we can add a sigaction for SIGINT too.
Besides, I patched 'fatal' procedure to display a friendly error message, without backtracking info, users will be frightened by these things.