On Sat, Jan 8, 2022 at 6: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.
Sqlite applies here, not bdb. But also note from that change, the rpmdb conversion to sqlite was not done during the system upgrade, but by a systemd unit. https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb Same for this change proposal. -- 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
