dmnks created an issue (rpm-software-management/rpm#4216)
**Describe the bug**
Commit 37636202f87ca4ab5d8c91a10c5131e3960d5186 ensured that the keystore lock
was always created, but missed the case where RPM is upgraded to a version with
that patch, in which case the lock file won't exist yet. This breaks regular
user queries after the upgrade since RPM then tries to create the keystore lock
and obviously fails due to missing permissions. Running RPM as root fixes that,
of course.
The question is, should this be handled on the packaging level, by triggering
an rpmdb rebuild after (this particular) upgrade? If so, the "fix" here is just
to add a note to the 6.1 release notes.
**To Reproduce**
Steps to reproduce the behavior:
1. Upgrade an existing system to the latest RPM 6.1.0 RC1 or a later snapshot
2. As a regular user: `rpm -qa`
**Actual behavior**
```
error: can't create keyring lock on /usr/lib/sysimage/rpm/.keyring.lock (No
such file or directory)
```
**Expected behavior**
No error.
**Environment**
- OS / Distribution: Fedora 44
- Version: RPM 6.1.0 RC1
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/4216
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/[email protected]>
_______________________________________________
Rpm-maint mailing list
[email protected]
https://lists.rpm.org/mailman/listinfo/rpm-maint
