[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