That addresses my concern. I'd assumed that it would occur as part of an RPM update, rather than as a triggered out of band event. It makes rebooting mandatory and slightly risky, especially if /usr overflows halfway through, the process, but that becomes far, far less likely with systemd doing it at boot time running at the same time other RPM updates. I do hope the scripting will exit gracefully if /usr overflows or is unwriteable for other reasons, such as being part of the "immutable" Linux concept.
Nico Kadel-Garcia On Sat, Jan 8, 2022 at 8:30 PM Chris Murphy <li...@colorremedies.com> wrote: > > 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 _______________________________________________ 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
