On Sat, Jan 8, 2022 at 7:53 AM Fabio Valentini <decatho...@gmail.com> wrote: > > On Sat, Jan 8, 2022 at 3:39 PM Neal Gompa <ngomp...@gmail.com> wrote: > > > > On Sat, Jan 8, 2022 at 8:58 AM Fabio Valentini <decatho...@gmail.com> wrote: > > > > > > On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton <bcot...@redhat.com> wrote: > > > > > > > > > > (snip) > > > > > > > > > > > == Detailed Description == > > > > === Current location === > > > > <pre>/var/lib/rpm</pre> > > > > > > > > === New location === > > > > <pre>/usr/lib/sysimage/rpm</pre> > > > > > > > > <code>/var/lib/rpm</code> will be a symlink pointing to > > > > <code>/usr/lib/sysimage/rpm</code> > > > > > > I did not find a mention of this in the thread or in the Change > > > proposal, so I'll ask: > > > How do you plan to handle the directory -> symlink replacement on upgrade? > > > > > > As far as I can tell, those always required special treatment via > > > %pretrans scriptlets or something, and even the method currently > > > recommended by the Packaging Guidelines seems to be broken due to the > > > way dnf / RPM verifies validity of transactions. > > > > > > Additionally, that "special" handling will probably need to stay in > > > the RPM package's .spec file for years, given that upgrades from > > > Fedora 34 to 36 will need to be supported. > > > > > > > This is documented in the Change: > > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Upgrade.2Fcompatibility_impact > > > > The part that's probably missing there is that the upgraded package > > will release ownership of /var/lib/rpm and own the > > /usr/lib/sysimage/rpm directory. > > > > The configuration will change in the upgrade, and then an rpmdb > > rebuild on reboot will finalize the transition, as rpmdb rebuilds are > > done by loading the rpmdb in memory, renaming the directory, > > recreating it, and re-initializing the database files from memory. > > > > This avoids the pitfalls you've described with the pretrans stuff. > > Oh, great. Looks like I'm ~tired~ and missed that this is in the > Change proposal after all ... > Thanks for confirming that you found a way to handle upgrades.
I did a manual proof of concept with the pseudo-sequence in the change proposal on a Fedora Rawhide VM. And it did work, and continues to do both GNOME Software and dnf updates OK. This is a sample size of 1, so there's more work to do to make sure it can be done safely, using the rpm sqlite upgrade as a guide. But I can write up the steps I used, so that anyone can test before we have it wired up. We have considered not applying the change to upgrades. Strictly speaking the release criterion say we only support upgrades from *clean installs* of the current two releases. But in practice quite a lot of users depend on reliable upgrades for *many* releases, and they get mad when things break even when it's been 10+ releases since they did a clean install. And also, Workstation edition PRD "upgrade process should give a result that is the same as an original install". That is a tall order, but so long as it's safe, it's probably better to apply this change to upgrades. If we run into issues or establish the risk is too high, it's not such a big deal to apply the change to only new clean installs. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
