DNF(一.YUM已死,DNF代之)

　　Yum还没学好呢,突然听到已经要被抛弃了.恐慌至极..

　　在最新版的Fedora 22 抛弃了Yum包管理器,取而代之的是DNF..

　　那么搜搜 Fedora 22 Release Note..

　　官方给出了解释和一些改变.

　　在最新的Fedora 22 试了下 基本的安装更新用法也没怎么变

　　以前安装 yum install httpd ,变成 dnf install httpd

以下是官方文档,有时间慢慢翻译..

3.6.1. Yum replaced by DNF

The yum package manager has been replaced in Fedora 22 by its successor, dnf. The yum fork has been available in Fedora for testing since Fedora 18, and is now the default command line package manager.

Most dnf commands use directives that are familiar to yum users, and it uses the same RPM package repositories. Behind the scenes, dnf uses an improved dependency solver, hawkey, along with librepo for repository operations and libcomps for package groups.

The /usr/bin/yum command will redirect to /usr/bin/dnf and print a warning about the redirection. The legacy yum package manager can be manually installed; the legacy command line utility has been renamed to yum-deprecated.

Read more about using dnf! Consult the upstream documentation athttp://dnf.readthedocs.org/en/latest/index.html. Extra plugins are documented at https://rpm-software-management.github.io/dnf-plugins-extras/index.htm

The behavior of dnf differs from yum in some areas:

3.6.1.1. Updates that don't work are skipped

If a portion of a transaction is not viable, dnf will automatically exclude it and transparently continue with the portions that will work. For example, if a package has unmet dependencies during a dnf update action, that package will not be updated, but others will. This is similar to yum's --skip-broken directive, but evaluates the impact of the problem against the entire transaction. Because this is the default behavior, there is no --skip-broken switch for dnf.

To reveal details about a problematic package direction, you can use the --best option. dnf update --best will force dnf to resolve the transaction using the latest versions of involved packages, and report any problems instead of skipping them. This is equivalent to yum's behavior without --skip-broken.

3.6.1.2. Repos that don't work are skipped

If a configured and enabled repository does not respond, dnf will skip it and continue the transaction with the available repos. This differs from yum, which would immediately stop if a repository was not available.

3.6.1.3. Update and Upgrade are the same

The commands dnf update and dnf upgrade are equivalent. This differs from yum, where yum upgrade would have the same effect as yum update --obsoletes, and take obsolete packages into account.

3.6.1.4. Dependencies are not upgraded on package installation

When installing a new package, previously installed dependencies will not be upgraded. Yum offered an option for this behavior, upgrade_requirements_on_install. To upgrade with dnf, use dnf update.

If dnf reports that dependencies on installed packages are unmet while installing a new package, update the dependent packages before trying again.

3.6.1.5. Clean on remove

When removing a package, dnf will automatically remove any dependent packages that were not explicitly installed by the user. If a package was independently installed, it won't be uninstalled this way. Only packages installed as dependencies are removed.

This behavior is configured by the clean_requirements_on_remove option in /etc/dnf/dnf.conf

3.6.1.6. Repo cache refresh schedule

By default, dnf will check for updates in configured repositories hourly, starting ten minutes after the system boots. The action is controlled by a systemd timer unit, /usr/lib/systemd/system/dnf-makecache.timer.

To adjust this, copy the timer file to /etc/systemd/system/dnf-makecache.timer and edit it.

Alternatively, setting the metadata_timer_sync in /etc/dnf/dnf.conf to a number of seconds configures the minimum number of seconds between makecache operations. If the timer has not expired, dnf makecache will exit immediately.

dnf will also honor the metadata_expire option set in individual repo configs, and refresh repo metadata at runtime if it is too old. This option is described in man yum.conf.

3.6.1.7. Repository Actions

The repository-packages directive can be used to search for or get info about packages in a specific repository, list installed packages from that repository, and more. This simplifies operations that would have required use of --excluderepo and --includerepo options with yum, and is especially useful for managing similar packages from different repositories.

3.6.1.8. Listing dependencies

To find out what package supplies a particular provide, use the dnf provides foo command. This replaces yum resolvedep foo.

To list the dependencies of a package, use dnf repoquery --requires foo. This replaces yum deplist foo.

3.6.1.9. dnf will remove kernels

kernel packages are not protected by dnf. Unlike with yum, you can remove all kernel packages, including the running package, if you direct it to. Be cautious with removing kernels, and specify the full version and release when removing them for best results.

3.6.1.10. Replacing packages

When a system requires the capabilities of a package you want to replace, use the --allowerasing option. For example, dnf --allowerasing mariadb will allow you to replace mysql with mariadb, without disrupting packages that require capabilities provided by both packages. This replaces yum shell and yum swap functionality.

3.6.1.11. DNF Langpacks Plug-in

DNF supports installing language packs using the dnf-langpacks plug-in, which is expected to work identically to the older yum-langpacks plug-in. See Section 4.3.3, “DNF Langpacks Plug-in” for details.

3.6.1.12. Support for disabled repositories

The Software tool and PackageKit now support searching for packages in disabled repositories.

If a user searches for a package using one of these applications and the package is found in a repository which includes the line enabled_metadata=1 in its definition, a dialog window will be displayed informing the user that the package has been found, but an additional repository must be enabled before it can be installed.

The same message can also inform the user about the reason why the repository is disabled by default.

This change allows Fedora remixes to ship pre-configured but disabled repositories for any reason - for example, if said repositories contain non-free software. Fedora itself does not have any such repositories pre-configured; therefore this feature will not be visible on a Fedora 22 installation unless you specifically configure one or more repositories with the enabled_metadata=1 statement.