I think I've stumbled into this. I was trying to use a public GitHub Actions
runner to create container images built from the `ubi-micro` images, which
don't have `dnf` installed within.
I found that `dnf --installroot=... install` failed because the PGP keys it
wanted weren't found in the RPM database. If I worked around that problem then
I found that the the container's RPM database in `/var/lib/rpm` was not being
updated by DNF. Instead, a new RPM database was created in
`/home/runner/.rpmdb`! The ultimate cause of both problems was a [a Debian
patch](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551669) which defines
%_dbpath as `~/.rpmdb`.
But this isn't specific to Debian either; the following is run on Fedora 39:
```
$ ctr=$(buildah from registry.access.redhat.com/ubi9/ubi-minimal)
$ mnt=$(buildah mount $ctr)
$ dnf --noplugins --releasever=9 --installroot="$mnt" list --installed | wc -l
0
$ chroot "$mnt" rpm -qa | wc -l
103
```
DNF sees no packages installed with the installroot, because the host
configuration defines `%_dbpath` as `/usr/lib/sysimage/rpm`, again different
from how it's defined in the `ubi-micro` container image.
I suppose what I've learned is that you can't really use a host's DNF/rpm to
install into a chroot if the distro/config differs too much between the host
and the chroot.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2735#discussioncomment-9174869
You are receiving this because you are subscribed to this thread.
Message ID:
<rpm-software-management/rpm/repo-discussions/2735/comments/9174...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
