More on project release notes.
We would like to invite you to DNF API hackfest session at DevConf which will be held on Sunday, February 8 at 10:40. The session is especially for the ones whose application is currently using yum/yum-utils and need to change the backend to DNF or for anyone who tries to write DNF plugin from scratch. You will have great opportunity to ask DNF developers for technical help.
See you there.
Your DNF team
Today we have started new project
dnf-plugins-extras where could be hosted any external DNF plugin with any dependencies.
We will add this package to Fedora soon. Then you can request new plugin and report a bug in RedHat Bugzilla. Sure, pull requests are welcomed to integrate any utilities with DNF!
Q: Why just not to add community plugins to core plugins?
A: We want to keep the core plugins minimal.
In following page is described the classification of common DNF bugs, what information to provide for each of them and what to attach. By filling right the bug reports you not only save time of DNF developers but you could raise the priority of your issue and eliminate wasteful delay of asking for additional problem description from us.
Thanks for properly filled bug reports so we can spend more time to fix your issues.
Dear users of YUM and DNF,
I’m writing to you regarding a request for your feedback. I would be very grateful if you could send me a brief description of how you use YUM or DNF currently or how would you like to use it. I am particularly interested in the occurrences of “dnf/yum install” calls in your scripts. What does these scripts do and what do they expect when they call the “install” command in different situations? Or even your own aliases, plugins, workarounds and the other hacks that you always need to do your job properly would be very interesting.
Please share with me the use cases, not the description of the “install” command. Think twice before you share something because I believe it’s not as easy as it might seem. As an example I think it might be something like:
- “I call YUM install, because I want to get given packages into my system and I don’t care whether it requires an upgrade or downgrade or what.” or
- “I want to get them there but it should protect me against dangerous operations like downgrades” or
- “I often make typos, so I expect that the program knows what I mean” or
- “it would be nice if it would literally perform the installation; if any of the packages cannot be installed because of any reason, it should fail”.
Not something like: “that’s obvious that the install command should never downgrade packages”.
Please focus on the use cases. The real (non-hypothetical) use cases. Not on the command’s name as it might also result in a new command (while preserving the well-known install command together with an appropriate behaviour).
Thank you very much in advance.
The DNF version 0.6.2 contains mostly bug fixes, improves database locking mechanism and does not request fresh metadata for every command. More information in release notes.
This is the last version of DNF under the lead of Ales Kozumplik – hopefully not the last stable/usable version of DNF. Thanks Ales for your hard work and knowledge you gave us.
As I will be moving on to work on other things beyond Linux software management soon, I decided to step down as a leader of the project.
The new leader of the project is Jan Šilhan, the change is effective as of today. Jan is a talented, result-oriented software developer and I am convinced he is just the right type for the job.
It has been exciting and fun three years and a big thanks to all of you who contributed, consulted, supported or generally shared the ride.
In new release is fully supported history redo command and is completed implementation of repository-packages commands.
DNF 0.6.1 introduces new config options (gpgkey, repo_gpgcheck and gpgcheck) and dnf-yum package. Aside from that a lot of bugs have been fixed.
For more details take a look at release notes.