Changes/MajorUpgradeOfMicrodnf

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.

Guidance
For details on how to fill out this form, see the documentation.

Major update Of Microdnf

Summary

Major upgrade of Microdnf is the first step in evolution of package management in Fedora. The new microdnf has ambitions to provide all major features of DNF without loosing its minimal footprint.

Owner

• Name: Jaroslav Mracek
• Email: jmracek@redhat.com

Current status

• Targeted release: Fedora Linux 38
• Last updated: 2022-03-24
• 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 new major microdnf will provide huge improvements and even in some cases better behavior then DNF. In the future the new microdnf will replace DNF. The new microdnf will be accompanied with a new library (libdnf5) and a new DNF Daemon.

MICRODNF features

• Improved user experience
  • Improved progress bars
  • Improved transaction table
  • Transaction progress reports including scriptlets reports
  • Support of local rpm for transaction operation
  • Great bash completion (better then DNF has)

LIBDNF5 features

• Fully integrated Modularity in LIBDNF workflows
  • Modularity is supported in DNF and LIBDNF but it is not fully integrated. Integration was not possible due to limitation of compatibility with other tools (PackageKit)
  • Fully integrated modularity requires changes in library workflow
• Unified user interface
  • DNF/YUM was developed for decades with impact of multiple styles and naming conventions (options, configuration options, commands)
• Plugins
  • DNF plugins are not applicable for PackageKit and Microdnf (e.g. versionlock, subscription-manager), therefore PackageKit behaves differently to DNF
• New plugins (C++, Python) will be available for all users
  • unified behaviour
  • Removal of functional duplicates
    • Decrease maintenance cost
• Shared configurations
  • In DNF4 the configuration is only partially honored by PackageKit and Microdnf
• New Daemon
  • The new daemon can provide an alternative to PackageKit for RPMs (only one backend of PackageKit) if it will be integrated into Desktop
• Additional improvements
  • Reports in structure (API)
    • DNF reports a lot of important information only in logs
• Shared cache and improved cache handling (Optional, not available in Fedora 38)
  • Microdnf, DNF4, and PackageKit use cached repositories on a different location with different cache structure.
• Performance improvement
  • Loading of repositories
  • Advisory operation
  • RPM query
    • Name filters with a case-insensitive search
  • Smart sharing of metadata between dnf, microdnf, daemon (Optional, not available in Fedora 38)
    • Reduce disk and downloads requirements
• Relocation of internal databases into /usr
  • Make rollback more easy

Downsides

• Relocation of internal databases and changed structure of internal databases
  • The transaction performed by the new MICRODNF will be not visible by DNF
  • The transaction performed by DNF or PackageKit will be not visible by the new MICRODNF
  • Packages installed by another packager will be handled as userninstalled
    • Consequence => The removal of a package will not trigger removal of unused dependencies
• Compatibility
  • To improve user experience and to unify dnf/microdnf behavior we were unable to keep 100% compatibility with formal microdnf in command-line and in behavior

Benefit to Fedora

The new MICRODNF significantly improves user experience and in future it will provide all important features of DNF. It will also keep all advantages of original MICRODNF like minimal size required by containers. The presence of MICRODNF, LIBDNF5, and DNFDAEMON in distribution will also allow smooth transition of components using dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora, and python3-dnfdaemon to a new library.

Scope

• Proposal owners:

• Other developers:

• Release engineering: #Releng issue number

• Policies and guidelines: N/A (not needed for this Change)

• Trademark approval: N/A (not needed for this Change)

• Alignment with Objectives:

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? N/A (not a System Wide Change), Yes/No

Documentation

N/A (not a System Wide Change)