check_lock currently claims the daemon is locked by another app
even if the problem is actually that it isn't locked at all.
We should distinguish these two cases.
Also, here and in a few other places we refer to this as either
a 'dnf lock' or a 'yum lock'. AFAICT it is not either of those
things, it is a lock that is internal to the daemon. You can
happily perform operations with dnf directly while this lock
is held. It's confusing to describe this as a 'dnf lock' when
that isn't what it is, so this changes the description to
'dnfdaemon lock' in a few places.
check_lock currently claims the daemon is locked by another app even if the problem is actually that it isn't locked at all. We should distinguish these two cases.
Also, here and in a few other places we refer to this as either a 'dnf lock' or a 'yum lock'. AFAICT it is not either of those things, it is a lock that is internal to the daemon. You can happily perform operations with dnf directly while this lock is held. It's confusing to describe this as a 'dnf lock' when that isn't what it is, so this changes the description to 'dnfdaemon lock' in a few places.
Signed-off-by: Adam Williamson awilliam@redhat.com