[Rpm-maint] RFC: Relocate RPM and DNF databases to /usr

Panu Matilainen pmatilai at redhat.com
Tue Dec 7 14:04:56 UTC 2021


On 12/7/21 06:00, Chris Murphy wrote:
> Hi RPM and DNF folks,
> 
> I have a draft change proposal for review and comment, i.e. it's not yet 
> set to be published to Fedora devel at . It's a bit thin, but I expect to 
> fill in more detail following discussion in this thread.
> 
> https://fedoraproject.org/wiki/Changes/RelocateRPMDNFToUsr 
> <https://fedoraproject.org/wiki/Changes/RelocateRPMDNFToUsr>
> 
> 
> The prior discussions for RPM have happened here:
> http://lists.rpm.org/pipermail/rpm-maint/2017-October/006681.html 
> <http://lists.rpm.org/pipermail/rpm-maint/2017-October/006681.html>
> http://lists.rpm.org/pipermail/rpm-maint/2017-October/006723.html 
> <http://lists.rpm.org/pipermail/rpm-maint/2017-October/006723.html>
> 
> Fedora 36 seems like a good time to do this. What do you think?

rpm-maint is about upstream rpm changes, and for an upstream change, the 
earliest something this drastic could go in would be 4.18 next year, 
presumably aligning with Fedora 37.

> Is it a given that the relocation should (or must) happen for upgrades? 
> What concerns do you have about relocating both databases during 
> offline-upgrade and ensuring its crash safe? When should the relocation 
> happen; as first or last order of business, or other?

It's not clear to me what exactly you're planning here. Are you talking 
about just following what openSUSE did or something more elaborate?

Technically, pointing rpm to a different database is a matter of 
changing exactly one macro in the configuration. Upgrade business 
generally needs to be left to the distro as rpm will have no way of 
knowing when it's appropriate to migrate and when it's an old chroot 
you're only wanting to peek at. Querying those old chroots and other 
images is something people do quite a lot, and chasing the correct path 
without creating new ones on the way certainly requires more than just a 
macro change.

	- Panu -

> 
> --
> Chris Murphy



More information about the Rpm-maint mailing list