On Tue, Dec 7, 2021 at 9:05 AM Panu Matilainen <pmati...@redhat.com> wrote: > > 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@. 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. >
The more appropriate list would have been rpm-ecosystem@, but many of the same people are on this list anyway... > > 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. I think the idea is to pull off the same migration openSUSE did. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
