On Wed, Apr 13, 2022 at 10:15 AM Vít Ondruch <vondr...@redhat.com> wrote:
> > Dne 12. 04. 22 v 22:54 Ben Cotton napsal(a): > > https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf > > > > == Summary == > > A major upgrade of Microdnf is the first step in the evolution of > > package management in Fedora. The new microdnf has ambitions to > > provide all major features of DNF without losing its minimal > > footprint. > > > > > > == Owner == > > * Name: [[User:jmracek| Jaroslav Mracek]] > > * Email: jmra...@redhat.com > > > > > > == Detailed Description == > > The new major Microdnf will provide huge improvements and in some > > cases better behavior then DNF. In the future, the new Microdnf will > > replace DNF. The new Microdnf will be accompanied by 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 currently supported in DNF and LIBDNF, but it is not > > fully integrated due to limitations in compatibility with other tools > > (PackageKit) > > ** Fully integrated Modularity requires changes in library workflow > > * Unified user interface > > ** DNF/YUM was developed for decades with the 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 behavior > > ** 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 the > > 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 different 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 > > > Thank you very much for very good questions. > Can you please elaborate what is the migration path? The new Microdnf will obsolete the old microdnf or new microdnf will have a higher version. What precisely will > be using the MICRODNF/libdnf5 in F38. The new Microdnf will use a new library `libdnf5` that will be parallel installable with `dnf` and `libdnf` > Will the DNF db be migrated? Right now I do not have the answer for that. > When > the DNF will be dropped or the switch from DNF to MICRODNF will happen? > I am going to create a System Wide Change for Fedora 39 to replace DNF with the new Microdnf. Jaroslav Vít > > > > > ** Packages installed by another packager will be handled as > userinstalled > > *** 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 the user experience and in the > > future it will provide all important features of DNF. It will also > > keep all advantages of the original MICRODNF, like minimal size > > required by containers. > > The presence of MICRODNF, LIBDNF5, and DNFDAEMON in the distribution > > will also allow for a smooth transition of components using `dnf`, > > `python3-dnf`, `python3-hawkey`, `libdnf`, `dnfdragora`, and > > `python3-dnfdaemon` to a new library. > > > > * 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) > > * `builddep` command without Python on the system > > > > > > == Scope == > > * Proposal owners: > > The new Microdnf is still in the development and some of the features > > or options are not yet available. We still have to finish the > > implementation of Modularity, storing internal data related to History > > and System State, and also documentation and man pages. The new > > Microdnf can be tested from repository with upstream nightly builds - > > > https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/ > . > > The project's github repository is here - > > https://github.com/rpm-software-management/libdnf/tree/dnf-5-devel > > > > > > * Other developers: > > > > * Release engineering: > > * 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 == > > > > > > == How To Test == > > > > > > == 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) > > * New commands and options that are only available with `DNF` > > > > == Dependencies == > > > > > > == 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) > > > > == Release Notes == > > > > > > > _______________________________________________ > 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
