From Fedora Project Wiki
(Add trackers)
 
(15 intermediate revisions by 3 users not shown)
Line 6: Line 6:


== Owner ==
== Owner ==
<!--
 
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
This should link to your home wiki page so we know who you are.
-->
* Name: [[User:chrismurphy| Chris Murphy]], [[User:Salimma|Michel Alexandre Salim]], [[User:Ngompa|Neal Gompa]]
* Name: [[User:chrismurphy| Chris Murphy]], [[User:Salimma|Michel Alexandre Salim]], [[User:Ngompa|Neal Gompa]]
* Email: chrismurphy@fedoraproject.org, salimma@fedoraproject.org, ngompa13@gmail.com
* Email: bugzilla@colorremedies.com, michel@michel-slm.name, ngompa13@gmail.com
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
-->
-->


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF36]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
 
<!-- Select proper category, default is Self Contained Change -->
<!-- [[Category:SelfContainedChange]] -->
[[Category:SystemWideChange]]
[[Category:SystemWideChange]]


Line 36: Line 25:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/G6LFNGOXZXFWZM3IWT6MLZWGMNSIZCWM/ devel thread]
* Tracker bug: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2731 #2731]
* Release notes tracker: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2042099 #2042099]
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/791 #791]


== Detailed Description ==
== Detailed Description ==
Line 49: Line 39:
<code>/var/lib/rpm</code> will be a symlink pointing to <code>/usr/lib/sysimage/rpm</code>
<code>/var/lib/rpm</code> will be a symlink pointing to <code>/usr/lib/sysimage/rpm</code>


Changing the file system layout to accommodate a snapshot+rollback regime is implied, but not required by this proposal. For example, Fedora has long placed `/home` on a separate subvolume (or file system) so it can be isolated from system root. Likewise, it makes sense to isolate `/var/log` and possibly `/var/lib/libvirt/images` so these locations continue to carry forward in time, even if the system root does a rollback.
 
* The RPM database primarily describes the state of `/usr`. Storing the databases in `/usr` will more easily facilitate OS snapshots and rollback, without affecting `/var`.
* The need for moving rpmdb to /usr was brought up in a [http://lists.rpm.org/pipermail/rpm-maint/2017-October/006681.html 2017 thread] on the upstream rpm-maint@ list. Various locations for rpmdb (and similar databases) is discussed in the thread, with the end result being `/usr/lib/sysimage/rpm`.
* There's upstream RPM, rpm-ostree, and (open)SUSE agreement for this location.
 
 
Note: Changing the file system layout to accommodate a snapshot+rollback regime is implied, but not required by this proposal. For example, Fedora has long placed `/home` on a separate subvolume (or file system) so it can be isolated from system root. Likewise, it makes sense to isolate `/var/log` and possibly `/var/lib/libvirt/images` so these locations continue to carry forward in time, even if the system root does a rollback.


== Feedback ==
== Feedback ==
Line 55: Line 51:
There will be no change to DNF as part of this change proposal. DNF's history will remain in `/var` until DNF 5. Discussion continues about the effect of a snapshot+rollback regime on DNF history. [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000769.html Relocate DNF history to /usr.]
There will be no change to DNF as part of this change proposal. DNF's history will remain in `/var` until DNF 5. Discussion continues about the effect of a snapshot+rollback regime on DNF history. [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000769.html Relocate DNF history to /usr.]


Upstream RPM accept the change, but institutionally don't like the loss or weakening of a [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html very well known location] for the database, and [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html anticipate complaints].
Upstream RPM accepts the change, but institutionally don't like the loss or weakening of a [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html very well known location] for the database, and [http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html anticipate complaints].  




== Benefit to Fedora ==
== Benefit to Fedora ==
* The RPM database primarily describes the state of `/usr`. Storing the databases in `/usr` will more easily facilitate OS rollback, without affecting `/var`.


* Helps align Fedora variants with each other
* Helps align Fedora variants with each other
** rpm-ostree based systems (including CoreOS, IoT, Silverblue, Kinoite) already use `/usr/lib/sysimage` for rpmdb.
** rpm-ostree based systems (including CoreOS, IoT, Silverblue, Kinoite) already use `/usr/lib/sysimage` for rpmdb.
 
* Consistency with another RPM-based distro, (open)SUSE have made this change.
* Consistency with another RPM-based distro, (open)SUSE has made this change
* Accounts for various snapshot+rollback regimes, i.e. it's a beneficial change whether Btrfs or device-mapper based.
 
* Is a preparatory step to support boot-to-snapshot and transactional update methods for dealing with problematic updates and upgrades.
* Accounts for various snapshot+rollback regimes, i.e. it's a beneficial change whether Btrfs or device-mapper based regimes.




Line 75: Line 68:
*** create the new path
*** create the new path
*** create a symlink for the old path pointing to new path
*** create a symlink for the old path pointing to new path
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
* Other developers:
 
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
** changes in SElinux policy
** changes in SElinux policy
** tracking bug for supermin: test if a package has been installed/updated/removed so that we can rebuild our cache
** tracking bug for libguestfs: build a "phony" Fedora image for testing with a fake RPM database
** possible bug in DNF when doing `dnf list` which writes to one or more rpmdb files (these might be file metadata changes not file data changes)




* Release engineering: [https://pagure.io/releng/issue/10441 #Releng issue 10441]
* Release engineering: [https://pagure.io/releng/issue/10441 #Releng issue 10441]
* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A (not needed for this Change)
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->
 
* Trademark approval: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
* Alignment with Objectives:


* Alignment with Objectives:


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
Line 109: Line 99:
# Check that `/usr/lib/sysimage/rpm` is populated with at least `rpmdb.sqlite`, possibly also `rpmdb.sqlite-shm` and `rpmdb.sqlite-wal`
# Check that `/usr/lib/sysimage/rpm` is populated with at least `rpmdb.sqlite`, possibly also `rpmdb.sqlite-shm` and `rpmdb.sqlite-wal`
# Confirm `rpm -q <package>` and/or `rpm -qa` still work
# Confirm `rpm -q <package>` and/or `rpm -qa` still work


== User Experience ==
== User Experience ==
Line 120: Line 111:
* `rpm-ostree` probably should make `/usr/share/rpm` a symlink to `/usr/lib/sysimage/rpm`, rather than the reverse as it is currently.
* `rpm-ostree` probably should make `/usr/share/rpm` a symlink to `/usr/lib/sysimage/rpm`, rather than the reverse as it is currently.
* `PackageKit` might use inotify on `/var/lib/rpm` need to check if it does and whether it should be changed or add the additional path
* `PackageKit` might use inotify on `/var/lib/rpm` need to check if it does and whether it should be changed or add the additional path


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Latest revision as of 19:58, 18 January 2022

Relocate RPM database to /usr

Summary

Currently, the RPM databases is located in /var. Let's move it to /usr. The move is already under way in rpm-ostree-based installations, and in (open)SUSE.

Owner

Current status

Detailed Description

Current location

/var/lib/rpm

New location

/usr/lib/sysimage/rpm

/var/lib/rpm will be a symlink pointing to /usr/lib/sysimage/rpm


  • The RPM database primarily describes the state of /usr. Storing the databases in /usr will more easily facilitate OS snapshots and rollback, without affecting /var.
  • The need for moving rpmdb to /usr was brought up in a 2017 thread on the upstream rpm-maint@ list. Various locations for rpmdb (and similar databases) is discussed in the thread, with the end result being /usr/lib/sysimage/rpm.
  • There's upstream RPM, rpm-ostree, and (open)SUSE agreement for this location.


Note: Changing the file system layout to accommodate a snapshot+rollback regime is implied, but not required by this proposal. For example, Fedora has long placed /home on a separate subvolume (or file system) so it can be isolated from system root. Likewise, it makes sense to isolate /var/log and possibly /var/lib/libvirt/images so these locations continue to carry forward in time, even if the system root does a rollback.

Feedback

There will be no change to DNF as part of this change proposal. DNF's history will remain in /var until DNF 5. Discussion continues about the effect of a snapshot+rollback regime on DNF history. Relocate DNF history to /usr.

Upstream RPM accepts the change, but institutionally don't like the loss or weakening of a very well known location for the database, and anticipate complaints.


Benefit to Fedora

  • Helps align Fedora variants with each other
    • rpm-ostree based systems (including CoreOS, IoT, Silverblue, Kinoite) already use /usr/lib/sysimage for rpmdb.
  • Consistency with another RPM-based distro, (open)SUSE have made this change.
  • Accounts for various snapshot+rollback regimes, i.e. it's a beneficial change whether Btrfs or device-mapper based.
  • Is a preparatory step to support boot-to-snapshot and transactional update methods for dealing with problematic updates and upgrades.


Scope

  • Proposal owners:
    • changes in rpm package
      • create the new path
      • create a symlink for the old path pointing to new path
  • Other developers:
    • changes in SElinux policy
    • tracking bug for supermin: test if a package has been installed/updated/removed so that we can rebuild our cache
    • tracking bug for libguestfs: build a "phony" Fedora image for testing with a fake RPM database
    • possible bug in DNF when doing dnf list which writes to one or more rpmdb files (these might be file metadata changes not file data changes)


  • Release engineering: #Releng issue 10441
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives:


Upgrade/compatibility impact

Change will be applied to offline upgrades, similar to the RPM sqlite database change. A systemd service will move the rpmdb from /var to /usr, then create a symlink pointing to /usr from /var.

  1. Create /usr/lib/sysimage/rpm (rpm package will do this at preinst)
  2. Create symlinks in /usr/lib/sysimage/rpm/ pointing to files in /var/lib/rpm/ (rpm package will do this at preinst)
  3. Change the dbpath in /usr/lib/rpm/macros to /usr/lib/sysimage/rpm (rpm package will be patched to do this on F36+)
  4. Request rpm rebuild the database (done via systemd service)
  5. Remove /var/lib/rpm and create a symlink /var/lib/rpm -> /usr/lib/sysimage/rpm (done via systemd service)


How To Test

  1. Perform a new clean install, or upgrade a system
  2. Check that /var/lib/rpm is a symlink to /usr/lib/sysimage/rpm
  3. Check that /usr/lib/sysimage/rpm is populated with at least rpmdb.sqlite, possibly also rpmdb.sqlite-shm and rpmdb.sqlite-wal
  4. Confirm rpm -q <package> and/or rpm -qa still work


User Experience

  • symlink /var/lib/rpm -> /usr/lib/sysimage/rpm

Otherwise, the change should be invisible to users.

Dependencies

  • rpm-ostree probably should make /usr/share/rpm a symlink to /usr/lib/sysimage/rpm, rather than the reverse as it is currently.
  • PackageKit might use inotify on /var/lib/rpm need to check if it does and whether it should be changed or add the additional path


Contingency Plan

  • Contingency mechanism: Revert the change, try again the next Fedora release.
  • Contingency deadline: Beta freeze
  • Blocks release? Yes


Documentation

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/RelocateRPMToUsr&oldid=635016"