On Sat, Jan 8, 2022 at 8:07 PM Nico Kadel-Garcia <nka...@gmail.com> wrote: > > On Sat, Jan 8, 2022 at 7:53 PM Chris Murphy <li...@colorremedies.com> wrote: > > > > 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. > > I'm personally concerned that the RPM transactions may not be handled > atomically if the /var/lib/rpm/ is migrated in the midst of an RPM > update. I'm not personally sure if RPM and Berkeley DB will handle > that correctly if there's any issues with the migration, particularly > if /usr/ overflows in the process of other bulky updates such as > libreoffice. Part of my work involves looking for where multiple > things can go wrong at once.
We're not doing the migration during the transaction itself. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
