doc: Add a chapter about migrating to dnf5
Try to retell the story of moving Fedora to dnf5 by default and what the migration process was like. Note this is different from the chapter explaining the differences between dnf4 and dnf5. Resolves: #1739 Resolves: SWM-4363 Signed-off-by: David Cantrell <dcantrell@redhat.com>
This commit is contained in:
David Cantrell
parent
ca1eaefc86
commit
9d3f528012
|
|
@ -21,6 +21,7 @@ Welcome to DNF5's documentation!
|
|||
best_practices/index
|
||||
templates/index
|
||||
changes_from_dnf4.7
|
||||
migrating_to_dnf5.7
|
||||
|
||||
|
||||
Indices and tables
|
||||
|
|
|
|||
|
|
@ -0,0 +1,196 @@
|
|||
.. _migrating_ref-label:
|
||||
|
||||
############################
|
||||
Migrating from DNF to DNF5
|
||||
############################
|
||||
|
||||
This chapter describes the changes that occurred on the system during
|
||||
the migration from `DNF
|
||||
<https://github.com/rpm-software-management/dnf>`_ to `DNF5
|
||||
<https://github.com/rpm-software-management/dnf5>`_. A number of
|
||||
Fedora releases were used to migrate the system from dnf4 to dnf5.
|
||||
Consider this chapter a historical account of what occurred rather
|
||||
than steps you can take to migrate a dnf4 system to dnf5.
|
||||
|
||||
.. _introducing_microdnf_ref-label:
|
||||
|
||||
Introducing microdnf
|
||||
====================
|
||||
|
||||
DNF was implemented in Python which means that a DNF-based system
|
||||
needs to have the Python stack installed and required modules. In
|
||||
most cases this is fine, but there are instances where people what an
|
||||
installed system that does not have Python at all. This presents a
|
||||
problem as the tool we provide to keep the system software updated
|
||||
requires Python.
|
||||
|
||||
The request to have a Pythonless system had always been around, but no
|
||||
one was really interested in coming up with a solution. Then
|
||||
containers showed up. We already had virtual machines and
|
||||
orchestration and now we have containers which are like chroot jails
|
||||
with a better set of management tools. Users want to use containers
|
||||
to isolate individual applications and services and in those
|
||||
containers they really do not want any unnecessary software. That
|
||||
includes Python. At first the response was to simply rebuild your
|
||||
container from scratch if system software needs updating, but users
|
||||
still wanted the ability to update a container on the fly. Now the
|
||||
Pythonless system request has higher priority.
|
||||
|
||||
The microdnf project was started to provide a dnf command that had
|
||||
compatible syntax, but was limited in functionality. It was written
|
||||
in C so it did not have to depend on Python, but that also meant it
|
||||
could not use dnf plugins and it also meant that a lot of advanced
|
||||
functionality simply was not implemented. The goal was to provide a
|
||||
dnf command for containers that could install, remove, and update
|
||||
packages all without requiring Python.
|
||||
|
||||
There is an obvious downside to this approach. The developers now
|
||||
have two dnf implementations to maintain. And the promise has been
|
||||
made that microdnf will maintain compatible CLI syntax. Still, this
|
||||
was the best short term solution for the growing demand of containers
|
||||
and wanting to have smaller and smaller installations. The dnf
|
||||
developers would have more time to come up with a long term solution.
|
||||
|
||||
|
||||
.. _introducing_dnf5_ref-label:
|
||||
|
||||
Introducing dnf5
|
||||
================
|
||||
|
||||
The developers decided that dnf was due for an overhaul given all of
|
||||
the current requirements. The decision was made that major version
|
||||
5.x of dnf would be implemented in C++ but contain bindings to support
|
||||
Python plugins as well as plugins written in other languages. The
|
||||
core functionality would be in C++ and would not require Python.
|
||||
There would also be a shared library that other applications could
|
||||
link with to gain dnf5 functionality.
|
||||
|
||||
A complete reimplementation of core system software is a big deal and
|
||||
the team had to carefully plan both the introduction of and migration
|
||||
to dnf5 in Fedora Linux. This is part of the reason the name of the
|
||||
software is dnf5 and not simply dnf. During the migration process it
|
||||
was possible to have both dnf and dnf5 installed concurrently.
|
||||
|
||||
These days the legacy dnf project is no longer actively developed,
|
||||
though patches are still accepted from distributions that are using
|
||||
it. New releases are occassionally made of the legacy dnf project,
|
||||
though that will likely stop in the future once no active OS is using
|
||||
it.
|
||||
|
||||
|
||||
.. _fedora_changes_ref-label:
|
||||
|
||||
Fedora Changes
|
||||
==============
|
||||
|
||||
The sections below discuss the changes in each Fedora Linux release
|
||||
that led to the eventual replacement of dnf with dnf5 in the core
|
||||
system.
|
||||
|
||||
|
||||
.. _fedora_linux_38_ref-label:
|
||||
|
||||
Fedora Linux 38
|
||||
---------------
|
||||
|
||||
The first part of the migration was to get the new tools in the hands
|
||||
of users. The microdnf project was refactored to be based on the new
|
||||
libdnf5 library meaning its backend would be the new dnf5 code base.
|
||||
In Fedora Linux 38, this new microdnf release along with dnf5 and
|
||||
libdnf5 were introduced to give users a new dnf stack to test and try
|
||||
out. The existing dnf stack remains the primary system dnf and
|
||||
officially supported one. Testers and early adopters of dnf5 at this
|
||||
point are made aware of the current limitations and the incompatible
|
||||
metadata between dnf and dnf5.
|
||||
|
||||
The change proposal: `MajorUpgradeOfMicrodnf
|
||||
<https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf>`_
|
||||
|
||||
|
||||
.. _fedora_linux_39_ref-label:
|
||||
|
||||
Fedora Linux 39
|
||||
---------------
|
||||
|
||||
Discontinue modularity support in dnf5. The Module Build Service was
|
||||
planned for shut down after Fedora Linux 38 reached EOL, so this
|
||||
release removed modularity support from the dnf5 stack.
|
||||
|
||||
The change proposal: `RetireModularity
|
||||
<https://fedoraproject.org/wiki/Changes/RetireModularity>`_
|
||||
|
||||
|
||||
.. _fedora_linux_40_ref-label:
|
||||
|
||||
Fedora Linux 40
|
||||
---------------
|
||||
|
||||
The next major step was to modify the Fedora build system tools (mock,
|
||||
koji, and copr) to use dnf5 instead of dnf. The idea here is to use
|
||||
the continually running build system as a burn in test for dnf5
|
||||
robustness and determine if we are ready to switch to dnf5 on the core
|
||||
system.
|
||||
|
||||
The change proposal: `BuildWithDNF5
|
||||
<https://fedoraproject.org/wiki/Changes/BuildWithDNF5>`_
|
||||
|
||||
An additional change was made to the dnf code base. Starting with
|
||||
this release of Fedora, dnf will no longer download filelists by
|
||||
default. This is metadata in the package repository that describes
|
||||
all of the files contained in each package. It was determined that
|
||||
this information is unnecessary in the majority of use cases, so the
|
||||
default was switched to not download filelists. This speeds up the
|
||||
program for many users which improves overall user experience.
|
||||
|
||||
The change proposal: `DNFConditionalFilelists
|
||||
<https://fedoraproject.org/wiki/Changes/DNFConditionalFilelists>`_
|
||||
|
||||
|
||||
.. _fedora_linux_41_ref-label:
|
||||
|
||||
Fedora Linux 41
|
||||
---------------
|
||||
|
||||
The final migration step is to move to dnf5 as the default on new
|
||||
installs and system upgrades. The existing dnf packages can remain
|
||||
installed, but the default becomes dnf5 going forward.
|
||||
|
||||
The new dnf5 packages will change symlinks on the system. Before
|
||||
upgrading, you will have symlinks that look like this:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ tree /usr/bin/ -P dnf*
|
||||
/usr/bin/
|
||||
├── dnf -> dnf-3
|
||||
├── dnf-3
|
||||
└── dnf4 -> dnf-3
|
||||
|
||||
And after upgrading, they will look like this:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ tree /usr/bin/ -P dnf*
|
||||
/usr/bin/
|
||||
├── dnf -> dnf5
|
||||
├── dnf-3
|
||||
├── dnf4 -> dnf-3
|
||||
└── dnf5
|
||||
|
||||
For new installs, the system will have symlinks that mirror the after
|
||||
upgrading example.
|
||||
|
||||
While both versions of dnf can remain installed and both use the same
|
||||
RPM database, the dnf state files differ between dnf4 and dnf5. When
|
||||
upgrading to dnf5, the system state is migrated from the existing dnf
|
||||
to dnf5, but the transaction history is not moved. You can continue
|
||||
using dnf4 and dnf5, but transactions are not recorded concurrently in
|
||||
each database. Packages installed with dnf5 and viewed under dnf4
|
||||
will show as user installed. Likewise, packages installed with dnf4
|
||||
and viewed under dnf5 will show as user installed. The metadata
|
||||
formats used for these databases in dnf are incompatible between dnf4
|
||||
and dnf5.
|
||||
|
||||
dnf4 continues to exist as other projects begin their migrations to
|
||||
dnf5 in Fedora. Users are encouraged to use dnf5 exclusively for
|
||||
daily operations.
|
||||
Loading…
Reference in New Issue