I think if I will start to talk that Fedora 26 is coming and that there will be DNF-2.x as default packager, I am not providing any new information.
But If I will say that DNF made a huge progress not only from point of presence of new features, enhanced stability and over all user experience, probably it would be something to attract people’s attention. The latest releases have provided the spirit with following highlights:
DNF-2.5.1 (since 2.4.1)
- Redesigned reports of problem. Now package upgrades will be not skipped silently
- Implemented progress of DRPM
- Localized datetime format
- Enhanced documentation
- Detailed information about DNF releases
DNF-PLUGINS-CORE-2.1.1 (since 2.0.0)
- Introduced DNF-UTILS subpackage that provides binaries previously known from YUM-UTILS
- Enhanced documentation of plugin Versionlock
- Plugin Versionlock will be not applied for commands without transaction like list, info, repoquery …
- Detailed information about DNF-PLUGINS-CORE releases
DNF-PLUGINS-EXTRAS-2.0.1 (since 2.0.0)
LIBDNF-0.9.1 (since 0.8.3)
- Improved handling of installonly packages and running kernel protection
- Improved reports from libsolv (no redundant messages in particular problem set)
- Install packages with lover version than already installed will allow downgrade of dependencies
- Methods (problem_conflicts(), problem_broken_dependency()) from python API where moved into C code
- Python property problem_rules where changed to method and moved into C code
Additionally all of this releases fixes together over 30 bugs in whole DNF stack.
The main aspect of the release is movement of several plugins from dnf-plugins-extras to dnf-plugins-core that became a part of core package or a separate sub-package. The release also provides new dnf option --enableplugin= , new option --userinstalled for REPOQUERY, and enables auto-detection of releasever from host if --releasever=/ is used. Additionally it fixes over 14 bugs in whole DNF stack, like a performance issue of VERSIONLOCK plugin, and added progress bar for download packages from command-line. For complete list of changes see DNF, DNF-PLUGINS-CORE and DNF-PLUGINS-EXTRAS release notes.
DNF 2.3.0 was released. The release adds new API property for Package class to return location from where the package can be downloaded from. The release introduce 7 new options for repoquery command, that were known from YUM. Additionally it fixes 4 bugs. For complete list of changes see DNF release notes.
DNF 2.2.0, and LIBDNF 0.8.0 were released. The release adds new API for adding and initialization of new REPO object into REPODICT class. Also interesting could be a new API callback that allows to inform users about running scriplets during RPM transaction. Additionally it also fixes over 13 bugs. For complete list of changes see DNF release notes.
DNF 2.1.0, DNF-PLUGINS-CORE 1.0.1, and DNF-PLUGINS-EXTRAS 0.10.0 released. Whole DNF stack release fixes over 20 bugs. DNF stack release is focused on bug fixes and yum-dnf compatibility. The release also provides two new commands (shell, and swap) that are formally known from YUM. For complete list of changes see DNF, DNF-PLUGINS-CORE and DNF-PLUGINS-EXTRAS 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
releasever of 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
--setopt using 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.