:thumbsup:

:thumbsup:

In kiwi, we used rpm to check what the %_dbpath variable was set to, I guess you can't do that here, right?

Nope, we're looking there from outside of mock/chroot, so macro is not visible in that point.

Commit fb202273 fixes this pull-request

Nope, we're looking there from outside of mock/chroot, so macro is not visible in that point.

For what it's worth, it's supposed to be possible to query macros from outside the root. In kiwi, we use rpm --root {path} --eval '%_dbpath' to do it properly.

Also, relying on the .migratedb file will not work if the system starts with /usr/lib/sysimage/rpm. It will also not work for openSUSE roots which never had that.

For what it's worth, it's supposed to be possible to query macros from outside the root. In kiwi, we use rpm --root {path} --eval '%_dbpath' to do it properly.

Hmm, not working correctly. It still uses host macros:

$ cat /etc/fedora-release
Fedora release 37 (Thirty Seven)
$ rpm --eval '%_dbpath'
/usr/lib/sysimage/rpm
$ rpm --root /var/lib/mock/fedora-35-x86_64/root/ --eval '%_dbpath'
/usr/lib/sysimage/rpm
$ mock -r fedora-35-x86_64 --chroot rpm --eval '%_dbpath'
...
/var/lib/rpm

It seems safer to me just do another mock call and ask rpm inside chroot.

It didn't happen in Fedora 35. Check Fedora 36.

Exactly, my point is that for F35 it returns wrong (non-existent) directory.

More specifically, the rpmdb path you queried is correct, since F35 uses /var/lib/rpm. It was F36 that changed to /usr/lib/sysimage/rpm.

Oh, I see what you're saying.

(This is what happens when it's 3:30am and I haven't slept yet. :zzz: )