DNF-2.0 has been released! The next major version release of DNF brings many user experience improvements such as better dependency problem reporting messages, weak dependencies shown in transaction summary, more intuitive help usage invoking and others. Repoquery plugin has been moved into DNF itself. Whole DNF stack release fixes over 60 bugs. DNF-2.0 release is focused on improving yum compatibility i.e. treat yum configuration options the same (`include`, `includepkgs` and `exclude`). Unfortunately this release is not fully compatible with DNF-1. See the list of DNF-1 and DNF-2 incompatible changes. Authors of dnf plugins will need to check compatibility of their plugins with the new DNF argument parser. For complete list of changes see DNF and plugins release notes.
I think quite a lot of users know the situation when you are unable to boot or run a system due to broken upgrade or problems created from the keyboard site. Recently I experience combination of both, but what then? First idea was to take out hard disk and connect it into working system, but then better idea appeared. The Fedora is delivered on boot-able live CD and I remembered that somewhere I have one. But will it work, and can I repair Fedora 25 from Fedora 23 live CD? Lets see what happened.
After booting from CD I checked if I can see the hard disk with broken system. I open from Activities application called Files and in “Other Locations” I opened the disk with Fedora 25. Data were there and I was happy that at least something is working. Now I moved my attention to terminal. I know that if I want to do repair I have to upgrade DNF of running system into DNF-2.0 from dnf-nightly repository on copr and I did (‘dnf copr enable rpmsoftwaremanagement/dnf-nightly’ then ‘dnf upgrade dnf’). The reason to do that was that dnf-2.0 provides many patches for installroot and additionally it provides commands like check or option –duplicates for remove command that are pretty handy for repair of the system.
The next question was how to find path to my broken system in terminal. I have seen that I have some directories with unique names (say crazy names) in root dir and I searched for them by ‘sudo find / -name <name_dir> ‘ or if you don’t have such, it is possible to create it in tmp/ dir on disk that you search for by Files, because for that directory you don’t need any special permission. From this research I got the path for –installroot option.
Consequently I was able to begin with repair. First I tried repolist command if I can see repositories of my original system and if releasever is correctly detected. Another good news, the command ‘dnf –installroot=/<path/to/disk> repolist‘ worked like expected. I know that accidentally I removed one package required by selinux and I successfully installed it by ‘dnf –installroot=/<path/to/disk> install selinux-policy-targeted‘. Then I started with removing of duplicates discovered by command ‘dnf –installroot=/<path/to/disk> check‘. The first attempt was with command ‘dnf –installroot=/<path/to/disk> remove –duplicates‘ but it didn’t work because I had some duplicates with unsatisfied dependencies, therefore it tried to remove too many packages. Therefore I continued with remove of each of duplicates by ‘dnf –installroot=/<path/to/disk> remove ‘. But this time I was very careful to not remove something that I don’t want, because for first time I tried to remove duplicate of selinux-policy and I remove the only copy that had installed all dependencies and kept the version that don’t have selinux-policy-targeted.
Last problems that remain on my system were duplicates of dnf and python3-dnf, but I was unable to remove them with information: Error: The operation would result in removing the following protected packages: dnf. Well here helped rpm (‘rpm -e ‘). Then I did upgrade of the system and everything looked good. It was the point when I tried if the system was repaired – reboot. And the system was again alive. The last question was if all packages were installed correctly from primary cause of the story – broken upgrade. I decided to do the last step, reinstall of all packages by “dnf reinstall ‘*’ ”.
This is the end of the story, my system works again due to Live CD technology and DNF-2.0.
Long live to Fedora and DNF.
I have seen several discussions about proper behavior of installroot and often it happened that what was requested by one user several others declined. But all of them had one thing common, that they would like to have proper description of installroot behavior. Now I can proudly announce that installroot entered new era where the behavior is slightly changed, but documented in detail.
Basically what was changed
- config file and reposdir are searched inside the installroot first. If they are not present, they are taken from host system. But when a path is specified within command line argument (–config= in case of config file or –setopt=reposdir= for reposdir) then this path is always related to the host with no exceptions.
- pluginconfpath is taken from installroot
If you think that reposdir behavior is not so new, you are completely right, because it is same like in YUM.
The documentation was also enhanced with following examples:
dnf --installroot=<installroot> --releasever=<release> install system-release
- Sets permanently the
releaseverof the system within
<installroot>directory from given
dnf --installroot=<installroot> --setopt=reposdir=<path> --config /path/dnf.conf upgrade
- Upgrade packages inside of installroot from repository described by
--setoptusing configuration from
I am really happy that I can say that additional information can be found in DNF documentation. Please have a fun with DNF.
DNF-2.0 is available for testing! The next major version release of DNF brings many user experience improvements such as more understandable dependency problem reporting messages, weak dependencies shown in transaction summary, more intuitive help usage invoking and others. Repoquery plugin has been moved into DNF itself. Whole DNF stack release fixes over 60 bugs. DNF-2.0 release is focused on getting rid of yum incompatibilities i.e. treat yum configuration options the same (`include`, `includepkgs` and `exclude`). Unfortunately this release is not fully compatible with DNF-1. See the list of DNF-1 and DNF-2 incompatible changes and prepare for the upcoming official release. Especially plugins will need to be changed to the new DNF argument parser. For complete list of changes see DNF and plugins release notes.
DNF is in EPEL for more than one year, unfortunately there was still the old DNF-0.6.4 version. Over that time in DNF were implemented a lot of great features and plenty of bugs have been fixed. DNF (especially its libraries) could not be updated in EPEL repository because of its policy. Now we have prepared fresh DNF-1.1.9 for RHEL 7 and CentOS 7 users in our COPR repository. Note this is still experimental preview not supported by Red Hat.
In order to get DNF-1.1.9 in RHEL 7 or CentOS 7:Enable EPEL repository for additional DNF dependencies:
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm # sudo rpm -Uvh epel-release-latest-7*.rpm
Add DNF stack repository:
# cat <<EOF > /etc/yum.repos.d/dnf-stack-el7.repo [dnf-stack-el7] name=Copr repo for dnf-stack-el7 owned by @rpm-software-management baseurl=https://copr-be.cloud.fedoraproject.org/results/@rpm-software-management/dnf-stack-el7/epel-7-\$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/@rpm-software-management/dnf-stack-el7/pubkey.gpg enabled=1 enabled_metadata=1 EOF
# yum install dnf
Enjoy the newest DNF
New version of DNF and DNF-PLUGINS-CORE is out. This release is focused on stability and should ease the transition for prepared DNF 2.0. Any call of not documented and so not supported Python methods should print warning. If you see them and you would like the methods to be included into DNF API, please, file an RFE (they will be vanished in DNF 2.0). In plugins the major improvements were made in repoquery – speedup of `- -resolve` and reverse queries on weak deps are working with glob expressions. More information about the release can be found in DNF and plugins release notes.
The new version of DNF and DNF-PLUGINS-CORE has been released. It’s a stability release with a bug fixes and user experience, translations and documentation improvements. At this time DNF-PLUGINS-CORE > 0.1.18 is needed to properly connect to COPR repositories, so please upgrade to the newest plugins to avoid potential COPR network problems. More information about the release can be found in DNF and plugins release notes.
Another release of DNF stack is there. In the new version of plugins there is support for debuginfo packages to be automatically upgraded along with the package they belong to and dnf repository-packages command was optimalized drastically. In addition over ten bugs were fixed in this release. Read more in DNF and plugins release notes.
As you already know, so far DNF has been using a bunch of C libraries (hawkey, librepo, libsolv, libcomps) while yum was written entirely in Python. From now some of the DNF code will be slowly rewritten into C, more precisely, moved into libhif project. The next milestone was reached by merging hawkey into libhif and further we plan to expand libhif to support general functionality of package managers.
Why have we merged hawkey into libhif
Nowadays there are three major consumers of hawkey – DNF, PackageKit and rpm-ostree. The hawkey API was not in final form yet and was changed constantly based on demands from these package managers. We have merged hawkey project inside libhif and hidden some of not yet stable API.
Merging hawkey into libhif was another step to move more code base of DNF into C. DNF will reuse some of the existing code of libhif. Having this shared library can eliminate inconsistencies about installed packages when DNF and PackageKit is used alternately. Moreover we would like to reuse the same metadata for all package managers to save your bandwidth.
Libhif should contain the common functionality for all package managers. So far libhif is providing high level API by taking care of fetching metadata from mirrors, doing dependency solving and executing RPM transaction. In the future it will support repository configuration parsing, GPG checking and so on. At this time, this is handled by all package managers separately.
Facts for Hawkey consumers:
- libhif-0.7.0 will obsolete hawkey package
- some of the C hawkey API from libhif will not be exposed anymore, please use libhif functions instead
- python bindings will not change and the libhif package will still provide
- API in libhif is still not considered as fully stable yet
- first release of libhif with hawkey inside is targeted for Fedora 25
Please watch libhif project on github and participate in pull request discussions so you can influence the development.