From Fedora Project Wiki
Line 62: Line 62:


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
* Rpmdb gets thoroughly exercised as a matter of normal system operation, performing installs, updates, package builds etc
 
* Of specific interest here is torture testing: forcibly killing rpm in various stages of execution - database should stay consistent and operational (other system state is out of scope)
Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
 
A good "how to test" should answer these four questions:
 
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this change? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the change is
working like it's supposed to?
3. What are the expected results of those actions?
-->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)  


== User Experience ==
== User Experience ==

Revision as of 08:42, 9 March 2020

Sqlite RpmDB

Summary

Change format of the RPM database from Berkeley DB to a new Sqlite format.

Owner

Current status

  • Targeted release: Fedora 33
  • Last updated: 2020-03-09
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The current rpm database implementation is based on Berkeley DB 5.x, a version which is unmaintained upstream for several years now. Berkeley DB 6.x is license incompatible so moving to that is not an option. In addition, the existing rpmdb implementation is notoriously unreliable as it's not transactional and has no other means to detect inconsistencies either.

Changing to a more sustainable database implementation is long overdue. We propose to change the default rpmdb format to the new sqlite based implementation. Support for current BDB format will be retained in Fedora 33, and phased out to read-only support in Fedora 34.

Benefit to Fedora

  • A far more robust rpm database implementation
  • Getting rid of Berkeley DB dependency in one of the core components

Scope

  • Proposal owners:
  • Other developers: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Upgrading

  • Ability to upgrade is not affected
  • After upgrade completes, manual action (rpmdb --rebuilddb) will probably be needed to convert to sqlite. Alternatively user can change configuration to stay on BDB.

Compatibility

  • Container/chroot use-cases will be affected: older rpm versions will be unable to query/manipulate the rpmdb from outside the chroot
  • Koji/COPR may need to override the database format (back to) BDB for the time being

How To Test

  • Rpmdb gets thoroughly exercised as a matter of normal system operation, performing installs, updates, package builds etc
  • Of specific interest here is torture testing: forcibly killing rpm in various stages of execution - database should stay consistent and operational (other system state is out of scope)

User Experience

  • In normal operation, users should see little or no change
  • Behavior in error situations is much more robust: forcibly killed transaction no longer causes database inconsistency or corruption

Dependencies

  • RPM will grow a new dependency on sqlite-libs
  • Technically the rpmdb format is an internal implementation detail of RPM only accessible through the librpm API, but some software is making assumptions both about the format and/or in particular, file naming. These are being tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1766120
  • Upgrade tooling could/should perform rpmdb rebuild at end, this would be a good thing to do regardless of this change

Contingency Plan

  • Contingency mechanism:

Revert the default database back to Berkeley DB backend in the package. Running 'rpmdb --rebuilddb' on hosts is currently required to actually convert the database, but means to automate conversion in specific conditions is being discussed upstream.

  • Contingency deadline: Beta freeze
  • Blocks release? Yes

Documentation

N/A (not a System Wide Change)

Release Notes

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