Monthly Archives: December 2014

Community plugins for DNF

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!

At this moment snapper plugin is available in the repository. It creates snapshots every transaction via snapper daemon, which is powerful tool to manage snapshots.

Q: Why just not to add community plugins to core plugins?
A: We want to keep the core plugins minimal.

How to report DNF bugs/RFEs

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.

Poll: How users use DNF

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.