Docs/quick-docs
2
0
Fork 0
Code Issues 48 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Remove references to yum.

Browse source 
We've been using DNF for the last 14ish releases, so let's simplify
things a little bit and not distract the reader.

Fixes #278
This commit is contained in:
Ben Cotton 2022-05-04 14:03:02 -04:00 • committed by bcotton
parent 99111b8c3a
commit 178b79779f
9 changed files with 35 additions and 50 deletions
Download patch file Download diff file Expand all files Collapse all files

3
modules/ROOT/pages/_partials/concept_third-party-repositories.adoc
View file

@ -10,5 +10,4 @@ The following repositories are commonly used by end users and do not conflict wi
== Mixing third party software repositories
Mixing a lot of third party repositories is not recommended since they might conflict with each other causing instability and hard to debug issues. If you are not a technical user, one way is to not enable the third-party repo by default and instead use the *--enablerepo* switch for yum or dnf, or a similar method configurable in the graphical package manager.
Mixing a lot of third party repositories is not recommended since they might conflict with each other causing instability and hard to debug issues. If you are not a technical user, one way is to not enable the third-party repo by default and instead use the *--enablerepo* switch for dnf, or a similar method configurable in the graphical package manager.

3
modules/ROOT/pages/_partials/proc_creating-and-using-live-cd.adoc
View file

@ -35,7 +35,8 @@ You can create a customized _kickstart_ file by running `system-config-kickstart
[NOTE]
====
You might have to install the package first with `dnf install system-config-kickstart` in Fedora 22 and beyond or `yum install system-config-kickstart` in earlier versions of Fedora. This tool is mainly intended for generating kickstart files for automated installs, not live images, so the output will probably not be usable without editing, but it may help you to generate particular kickstart directives. Remember to add the line `%include /usr/share/spin-kickstarts/fedora-live-base.ks` at the beginning of your _kickstart_ file to include the base live configuration.
You might have to install the package first with `dnf install system-config-kickstart`.\
This tool is mainly intended for generating kickstart files for automated installs, not live images, so the output will probably not be usable without editing, but it may help you to generate particular kickstart directives. Remember to add the line `%include /usr/share/spin-kickstarts/fedora-live-base.ks` at the beginning of your _kickstart_ file to include the base live configuration.
====
[id='making-the-image']

2
modules/ROOT/pages/_partials/ref_the-most-useful-dnf-commands.adoc
View file

@ -180,7 +180,7 @@ sssd-common-1.14.2-1.fc25.x86_64 : Common files for the SSSD
Repo : fedora
----
*dnf history*:: Displays a report of the past *yum* transactions.
*dnf history*:: Displays a report of the past transactions.
+
[literal,subs="+quotes,attributes"]
----

25
modules/ROOT/pages/anaconda/anaconda_logging.adoc
View file

@ -20,17 +20,15 @@ During the installation the logs are stored in the `/tmp` directory:
`/tmp/anaconda.log`:: the general installation information, particularly the step changes.
`/tmp/storage.log`:: storage devices scan and manipulation (hard drives, partitions, LVM, RAID), partitioning
`/tmp/program.log`:: calls to external programs, their output
`/tmp/syslog`:: messages from kernel and external programs (Network Manager)
`/tmp/yum.log`:: yum's internal log
`/tmp/dnf.log`:: link:https://www.fedoraproject.org/wiki/Dnf[DNF]'s internal log
`/tmp/dnf.hawkey.log`:: link:https://www.fedoraproject.org/wiki/Dnf[DNF]'s Hawkey internal log
`/tmp/dnf.rpm.log`:: link:https://www.fedoraproject.org/wiki/Dnf[DNF]'s RPM internal log
`/tmp/packaging.log`:: xref:dnf.adoc[DNF] package installation messages
`/tmp/syslog`:: hardware-related system messages
Certain log messages are also written to the terminals:
=== TTY devices
`/dev/tty3`:: messages from `anaconda.log`, `storage.log` and `yum.log`.
`/dev/tty3`:: messages from `anaconda.log`, `storage.log` and `packaging.log`.
`/dev/tty4`:: same as `syslog`
`/dev/tty5`:: stdout and stderr from external programs +
@ -42,7 +40,7 @@ There are two other log files created on the target filesystem, in the `/root` d
`/mnt/sysimage/root/install.log`:: log of the package installation process.
`/mnt/sysimage/root/install.log.syslog`:: messages from installation chroot logged through the system's syslog.
Mostly information about users and groups created during dnf|yum's package installation.
Mostly information about users and groups created during dnf's package installation.
=== Log format
In files the format of the log messages is as follows:
@ -188,17 +186,12 @@ To avoid name clashes with other log files there, the anaconda logs are renamed:
[%header,cols=2*]
|====
| Name during installation | Name on the target system
| `/tmp/anaconda.log` | `/var/log/anaconda.log`
| `/tmp/syslog` | `/var/log/anaconda.syslog`
| `/tmp/X.log` | `/var/log/anaconda.xlog`
| `/tmp/program.log` | `/var/log/anaconda.program.log`
| `/tmp/storage.log` | `/var/log/anaconda.storage.log`
| `/tmp/yum.log` | `/var/log/anaconda.yum.log`
| `/tmp/ifcfg.log` (new in F14) | not copied
| `/tmp/anaconda.log` | `/var/log/anaconda/anaconda.log`
| `/tmp/program.log` | `/var/log/anaconda/program.log`
| `/tmp/storage.log` | `/var/log/anaconda/storage.log`
| `/tmp/packaging.log` | `/var/log/anaconda/packaging.log`
|====
Starting with Fedora 15 (or post F14 Rawhide), the logs go to `/var/log/anaconda` directory on the target system, including ifcfg.log inroduced in F14.
== Logging tips
If you are asked to provide logs for a bugzilla, your best option is switching from the anaconda GUI to tty2 and then use scp to copy the files to your computer, e.g.:

2
modules/ROOT/pages/autoupdates.adoc
View file

@ -228,7 +228,7 @@ packages, or installed updates according to settings in `automatic.conf`.
As an alternative to dnf-automatic,
https://github.com/rackerlabs/auter[auter] can be used. This operates in
a similar way to yum-cron, but provides more flexibility in scheduling,
a similar way to dnf-automatic, but provides more flexibility in scheduling,
and some additional options including running custom scripts before or
after updates, and automatic reboots. This comes at the expense of
more complexity to configure.

22
modules/ROOT/pages/package-management.adoc
View file

@ -12,9 +12,8 @@ Fedora is a distribution that uses a package management system. This
system is based on https://rpm.org[rpm] , the RPM Package Manager, with
several higher level tools built on top of it, most notably
https://www.freedesktop.org/software/PackageKit/[PackageKit] (default
gui) and Yum (command line tool). As of Fedora 22, yum has
been replaced by xref:dnf.adoc[DNF]. The Gnome Package Manager is another
GUI package manager.
gui) and xref:dnf.adoc[DNF].
GNOME Software is another GUI package manager.
[[advantages-of-package-management-systems]]
Advantages of package management systems
@ -90,7 +89,7 @@ Preferred search order for a software
If some software is missing in your installation then you should try the
following steps to get the packaged version:
1. Search in Fedora ( 'yum|dnf search foo' or search for 'foo' in the
1. Search in Fedora ( 'dnf search foo' or search for 'foo' in the
PackageKit gui )
2. Try one of the available xref:finding-and-installing-linux-applications.adoc#_enabling_third_party_repositories[third-party repositories]
3. xref:package-maintainers::Packaging_Tutorial_GNU_Hello.adoc[Build your own package]
@ -99,16 +98,15 @@ following steps to get the packaged version:
Package Management tools
~~~~~~~~~~~~~~~~~~~~~~~~
xref:dnf.adoc[dnf] - Dandified Yum
Here are some tools for managing packages:
https://www.freedesktop.org/software/PackageKit/[PackageKit] -
* xref:dnf.adoc[dnf] - Dandified Yum
* https://www.freedesktop.org/software/PackageKit/[PackageKit] -
PackageKit gui tool ('add/remove software' in your menu)
https://rpm.org[rpm] - RPM package manager.
https://github.com/timlau/yumex-dnf[yumex] - Yum Extender.
Category:Software_Management[Category:Software Management]
* https://wiki.gnome.org/Apps/Software[GNOME Software] - ­Graphical package manager for GNOME
* https://apps.kde.org/discover/[KDE Discover] - Graphical pacakge manager for KDE Plasma
* https://rpm.org[rpm] - RPM package manager.
* https://github.com/timlau/yumex-dnf[yumex] - Yum Extender.
'''
See a typo, something missing or out of date, or anything else which can be

12
modules/ROOT/pages/repositories.adoc
View file

@ -11,7 +11,7 @@ packages they contain.
[[the-fedora-repository]]
== The fedora repository
The _fedora_ repository exists for all Fedora releases after they have link:https://fedoraproject.org/wiki/Releases/Branched[Branched] from link:https://fedoraproject.org/wiki/Releases/Rawhide[Rawhide]. It is represented for Yum or http://dnf.baseurl.org/[DNF] in the `fedora.repo` file in the repository path. For any Fedora installation, this repository will be enabled by default, and should usually remain so.
The _fedora_ repository exists for all Fedora releases after they have link:https://fedoraproject.org/wiki/Releases/Branched[Branched] from link:https://fedoraproject.org/wiki/Releases/Rawhide[Rawhide]. It is represented for xref:dnf.adoc[DNF] in the `fedora.repo` file in the repository path. For any Fedora installation, this repository will be enabled by default, and should usually remain so.
[[the-fedora-repository-in-stable-releases]]
=== The _fedora_ repository in stable releases
@ -30,7 +30,7 @@ The Branched _fedora_ repositories for the various primary https://fedoraproject
[[the-updates-repository]]
== The _updates_ repository
The _updates_ repository exists for Branched and stable releases, but is only populated and used for stable releases. It is represented for Yum or http://dnf.baseurl.org/[DNF] in the `fedora-updates.repo` file in the repository path. It exists in Branched releases solely to prevent various tools that expect its existence from breaking. For any Fedora installation, this repository will be enabled by default, and should usually remain so.
The _updates_ repository exists for Branched and stable releases, but is only populated and used for stable releases. It is represented for xref:dnf.adoc[DNF] in the `fedora-updates.repo` file in the repository path. It exists in Branched releases solely to prevent various tools that expect its existence from breaking. For any Fedora installation, this repository will be enabled by default, and should usually remain so.
For stable releases, _updates_ together with _fedora_ represents the current _stable_ state of the release. Package builds that pass the https://fedoraproject.org/wiki/Updates_Policy[Updates Policy] move from the _updates-testing_ repository to this repository. This difference from Branched is a result of the need to maintain a precise representation of the initial, 'frozen' state of a stable release.
@ -39,21 +39,21 @@ The stable release _updates_ repositories for the various primary architectures
[[the-updates-testing-repository]]
=== The _updates-testing_ repository
The _updates-testing_ repository exists for Branched releases after the https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling[Bodhi enabling point], and for stable releases. It is represented for Yum or http://dnf.baseurl.org/[DNF] in the `fedora-updates-testing.repo` file in the repository path. For both, it is a 'staging' location where new package builds are tested before being marked as 'stable' (and hence moving to the _fedora_ repository or the _updates_ repository, respectively).
The _updates-testing_ repository exists for Branched releases after the https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling[Bodhi enabling point], and for stable releases. It is represented for xref:dnf.adoc[DNF] in the `fedora-updates-testing.repo` file in the repository path. For both, it is a 'staging' location where new package builds are tested before being marked as 'stable' (and hence moving to the _fedora_ repository or the _updates_ repository, respectively).
These builds are sometimes referred to as _update candidates_, and are reviewed with the https://fedoraproject.org/wiki/Bodhi[Bodhi] update feedback tool, according to the
https://fedoraproject.org/wiki/QA:Update_feedback_guidelines[update feedback guidelines].
The https://fedoraproject.org/wiki/Updates_Policy[Updates Policy] defines the rules for marking update candidates as _stable_. The https://fedoraproject.org/wiki/QA:Updates_Testing[QA updates-testing page] provides some information for testers on using this repository. The https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/[Package Update Guide] provides information for packagers on submitting builds to _updates-testing_ and to _stable_.
The _updates-testing_ repository is enabled by default for Branched releases, but disabled by default for stable releases. The switchover is made around the time of the https://fedoraproject.org/wiki/Milestone_freezes[Final Freeze] for each release. Testers moving from Branched to stable may encounter errors running updates around this time, caused by dependency mismatches between packages already installed from the now-disabled _updates-testing_ repository. Running `dnf distro-sync`(or with yum command) or re-enabling the _updates-testing_ repository will both usually alleviate the issue; it is up to the individual user whether they wish to continue using the _updates-testing_ repository after the stable release or not.
The _updates-testing_ repository is enabled by default for Branched releases, but disabled by default for stable releases. The switchover is made around the time of the https://fedoraproject.org/wiki/Milestone_freezes[Final Freeze] for each release. Testers moving from Branched to stable may encounter errors running updates around this time, caused by dependency mismatches between packages already installed from the now-disabled _updates-testing_ repository. Running `dnf distro-sync` or re-enabling the _updates-testing_ repository will both usually alleviate the issue; it is up to the individual user whether they wish to continue using the _updates-testing_ repository after the stable release or not.
The _updates-testing_ repositories for both Branched and stable releases can be found in the `/fedora/linux/updates/testing/XX` directory on the mirrors (where XX is the release), and can also be queried from https://fedoraproject.org/wiki/MirrorManager[MirrorManager]. For instance, https://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f{FedoraVersionNumber}&arch=x86_64 will return mirrors for the x86_64 _updates-testing_ repository for release {FedoraVersionNumber}.
[[the-rawhide-repository]]
=== The _rawhide_ repository
In Rawhide - Fedora's rolling release repository, from which release are Branched before finally going stable - _rawhide_ is the only repository. All package builds are sent there. It is represented for Yum or http://dnf.baseurl.org/[DNF] in the `fedora-rawhide.repo` file in the repository path. For any system running Rawhide, it should be enabled. For any other system, it should not.
In Rawhide - Fedora's rolling release repository, from which release are Branched before finally going stable - _rawhide_ is the only repository. All package builds are sent there. It is represented for xref:dnf.adoc[DNF] in the `fedora-rawhide.repo` file in the repository path. For any system running Rawhide, it should be enabled. For any other system, it should not.
The _rawhide_ repositories for the various primary https://fedoraproject.org/wiki/Architectures[architectures] can be found in the directory on the mirrors, and can also be queried from https://fedoraproject.org/wiki/MirrorManager[MirrorManager]. For instance, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64 will return mirrors for the x86_64 _fedora_ repository for Rawhide.
@ -81,7 +81,7 @@ The Product trees for the GA (Final) release are made available in the `/release
At any given point in the release cycle, the MirrorManager request for a Product repository may redirect to a test compose / release candidate tree, a pre-release milestone tree, or the Final release tree.
These repositories are usually not used or enabled by default on installed systems, as for that purpose they are redundant with one of the three primary repositories described above. However, one could use a Product repository in place of the _fedora_ repository to keep a system limited to the Product package set. They are represented for Yum or http://dnf.baseurl.org/[DNF] in the `fedora-(product).repo` file in the repository path, which may well not be installed on many systems.
These repositories are usually not used or enabled by default on installed systems, as for that purpose they are redundant with one of the three primary repositories described above. However, one could use a Product repository in place of the _fedora_ repository to keep a system limited to the Product package set. They are represented for xref:dnf.adoc[DNF] in the `fedora-(product).repo` file in the repository path, which may well not be installed on many systems.
[[other-repositories]]
== Other repositories

3
modules/ROOT/pages/upgrading-fedora-online.adoc
View file

@ -72,7 +72,8 @@ TIP: *Find unused config files* + Merge and resolve the changes found by the fol
Now is a good time to remove packages you don't use - especially
non-standard packages.
TIP: *Find and review "unused" packages* + You can find packages not required by other packages with the tool `package-cleanup` from the `yum-utils` package: `dnf install yum-utils; package-cleanup --leaves`. These packages could be candidates for removal, but check to see whether you use them directly or if they are used by applications not backed by rpm packages. Remove them with `dnf remove package-name-and-version`.
TIP: *Find and review "unused" packages* + You can find packages not required by other packages with the tool `package-cleanup` from the `dnf-utils` package: `dnf install dnf-utils; package-cleanup --leaves`.
These packages could be candidates for removal, but check to see whether you use them directly or if they are used by applications not backed by rpm packages. Remove them with `dnf remove package-name-and-version`.
Another useful tool for cleaning up unused packages is `rpmreaper`. It's an ncurses application that lets you view rpm dependency graph and mark packages for deletion. Marking one package can make other packages leaf, which you can see immediately, so you don't have to run the tool several times to get rid of a whole sub-tree unused packages. Install with `dnf install rpmreaper`.
TIP: *Find and review "lost" packages* + You can find orphaned packages (i.e. packages not in the repositories anymore) with `package-cleanup --orphans`. This will also show packages which have been partially uninstalled but where the "%postun" script failed.

13
modules/ROOT/pages/upgrading.adoc
View file

@ -5,8 +5,7 @@
====
. Be sure to *back-up your data* before upgrading your Fedora system in the event something breaks and leaves your system unusable.
. Read the link:++https://fedoraproject.org/wiki/Releases#Current_Supported_Releases++[Release
Notes] carefully before attempting an upgrade.
. Read the xref:fedora:release-notes:index.adoc[Release Notes] carefully before attempting an upgrade.
====
@ -85,14 +84,8 @@ Upgrading to a Branched release or to Rawhide can be done using xref:dnf-system-
Fedora strongly discourages running an end-of-life release on any production system, or any system connected to the public internet.
You should never allow a production Fedora deployment to reach end-of-life in the first place.
With that in mind, if you do have an end-of-life release installed on a system you cannot just discard or re-deploy, you can attempt to upgrade it, though this is not officially tested or supported.
If you have Fedora 21 or later, you can try to upgrade using xref:dnf-system-upgrade.adoc[DNF System Upgrade].
If you have Fedora 20 or earlier, you will have to perform at least part of the upgrade with bare `yum`.
You can either use that method to upgrade to Fedora 21 or later and then use DNF system upgrade to upgrade from there to a currently-supported release, or just use bare `dnf` or `yum` for the entire upgrade process.
Note that when upgrading from Fedora 20 or earlier, you are both upgrading from an end-of-life release and using a not-officially-recommended upgrade mechanism; such upgrades are very much performed 'at your own risk' and may well require various kinds of manual intervention to run and clean up the upgraded system, if they work at all.
With that in mind, if you do have an end-of-life release installed on a system you cannot just discard or re-deploy, you upgrade using xref:dnf-system-upgrade.adoc[DNF System Upgrade].
Note that upgrades are only tested from the two previous releases.
[[sect-upgrading-using-the-fedora-installer-anaconda]]
=== Upgrading using the Fedora installer (anaconda)?