From Fedora Project Wiki
< Changes
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to i...") |
|||
| (11 intermediate revisions by 3 users not shown) | |||
| Line 18: | Line 18: | ||
--> | --> | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
= Unified database for DNF <!-- The name of your change proposal --> = | = Unified database for DNF <!-- The name of your change proposal --> = | ||
== Summary == | == Summary == | ||
Replacing obsoleted YUM/DNF databases (yumdb, historydb, groups.json) with new unified sqlite database adapted to the current needs of DNF. | Replacing obsoleted YUM/DNF databases (yumdb, historydb, groups.json) with new unified sqlite database adapted to the current needs of DNF. | ||
== Owner == | == Owner == | ||
| Line 30: | Line 29: | ||
This should link to your home wiki page so we know who you are. | This should link to your home wiki page so we know who you are. | ||
--> | --> | ||
* Name: [[User:edynox|Eduard Čuba | * Name: [[User:edynox|Eduard Čuba]] | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: ecuba@redhat.com | * Email: ecuba@redhat.com | ||
| Line 57: | Line 56: | ||
== Detailed Description == | == Detailed Description == | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
Unified software database for DNF is replacing outdated and obsolete databases behind the DNF. It comes with shared library for accessing the database used by DNF and PackageKit. Library providing database access should be part of libdnf. | Unified software database for DNF is replacing outdated and obsolete databases behind the DNF. It comes with shared library for accessing the database used by DNF and PackageKit. Library providing database access should be part of libdnf. | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
Using single unified database with shared interface enhances data integrity, safety and performance of package managers in Fedora. Database is easily expandable for new features( | Using single unified database with shared interface enhances data integrity, safety and performance of package managers in Fedora. Database is easily expandable for new features (Modularity support in DNF will use SWDB). | ||
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?--> | ||
== Scope == | == Scope == | ||
* Proposal owners: Port DNF to SWDB (patches has been already sent), [[GSOC_2017/Student_Application_edynox|Port PackageKit to SWDB]] | * Proposal owners: Port DNF to SWDB (patches has been already sent), [[GSOC_2017/Student_Application_edynox|Port PackageKit to SWDB]] | ||
| Line 72: | Line 70: | ||
<!-- 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?--> | <!-- 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?--> | ||
* Release engineering: [https://pagure.io/releng/ | * Release engineering: [https://pagure.io/releng/issue/6886 #6886] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES --> | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: | ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: Change affects whole distro rather than some derivable | ||
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --> | <!-- Please check the list of Fedora release deliverables and list all the differences the feature brings --> | ||
* Policies and guidelines: | * Policies and guidelines: Nothing is required <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- 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. --> | <!-- 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. --> | ||
* 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://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. --> | <!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. --> | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? | <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | ||
Data from obsolete databases are migrated to SWDB with first use of ported DNF. There is no backward migration available. | Data from obsolete databases are migrated to SWDB with first use of ported DNF. There is no backward migration available. | ||
| Line 103: | Line 101: | ||
working like it's supposed to? | working like it's supposed to? | ||
3. What are the expected results of those actions? | 3. What are the expected results of those actions? | ||
--> | |||
Use DNF in normal operation (especially history commands). | Use DNF in normal operation (especially history commands). | ||
Latest revision as of 08:25, 8 August 2017
Unified database for DNF
Summary
Replacing obsoleted YUM/DNF databases (yumdb, historydb, groups.json) with new unified sqlite database adapted to the current needs of DNF.
Owner
- Name: Eduard Čuba
- Email: ecuba@redhat.com
- Release notes owner:
Current status
- Targeted release: Fedora 27
- Last updated: 2017-08-08
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
Unified software database for DNF is replacing outdated and obsolete databases behind the DNF. It comes with shared library for accessing the database used by DNF and PackageKit. Library providing database access should be part of libdnf.
Benefit to Fedora
Using single unified database with shared interface enhances data integrity, safety and performance of package managers in Fedora. Database is easily expandable for new features (Modularity support in DNF will use SWDB).
Scope
- Proposal owners: Port DNF to SWDB (patches has been already sent), Port PackageKit to SWDB
- Other developers: PackageKit developers should review proposed changes in libdnf for logging PackageKit transactions into SWDB instead of yumdb. In addition PackageKit developers should consider using SWDB for reading transaction data instead of using its own backend.
- Release engineering: #6886 (a check of an impact with Release Engineering is needed)
- List of deliverables: Change affects whole distro rather than some derivable
- Policies and guidelines: Nothing is required
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
Data from obsolete databases are migrated to SWDB with first use of ported DNF. There is no backward migration available.
How To Test
Use DNF in normal operation (especially history commands).
User Experience
Increase of history related DNF commands performance.
Dependencies
Changing DNF databases in the background should not affect other packages.
Contingency Plan
- Contingency mechanism: Write tool to convert to old db format and revert change
- Contingency deadline: Beta Freeze
- Blocks release? Yes (not sure)
- Blocks product? -
Documentation
Not written yet.