Monthly Archives: March 2014

Copr Plugin

(contributed by Miroslav Suchý)

New dnf-plugins-core introduces new copr plugin.

You can list projects of some user:

  # dnf copr list bkabrda
  ==================== List of bkabrda coprs =====================
  bkabrda/python27rebuild : Collection with Python 2.7 for EPEL 6
                          : (currently just for testing).
  bkabrda/python-3.4 : Testing repository for Python 3.4 that is
                     : supposed to go to F21. 

We have plan for generic search function as well, but it will land in some future version.

You can easily enable some project:

 # dnf copr enable bkabrda/python-3.4 fedora-20-x86_64

 You are going to enable Copr repository. Please note that this repository is not
 part of Fedora distribution and may have various quality. Fedora distribution
 have no power over this repository and can not enforce some quality or security
 level.

 Please do not file bug reports about this packages in Fedora Bugzilla.
 In case of problems you should contact owner of this repository.

 Do you want to continue? [y/N]: y 
 Repository successfully enabled.

You can even omit last argument and it will be guessed. But currently there is know bug, which will
be fixed in next release, therefore you need to specify chroot.
This command will download repo file and save it as /etc/yum.repos.d/_copr_bkabrda-python-3.4.repo

You can disable project:

 # dnf copr disable bkabrda/python-3.4 
 Repository successfully disabled.

which will remove previously downloaded repo file.

DNF 0.4.18 Released

The new release is making its way to Fedora mirrors as I write this. The notes are up.

Distro-syncing specific subsets of packages is finally here. Also 0.4.18 marks the move to objectified groups, something Yum did in 2012. Things might look a bit shaky on the groups front for some time while the precise semantics settles but the basic operations work and support for installing optional packages has been added again. Moreover, the changes provide new API that allows the DNF Anaconda payload to exclude packages from transaction as the user wishes.

API also sees some spring cleaning of parts that we’ve deprecated and kept in the cellar since last December.

On The Name

With the DNF Fedora change published, the feature set closing in on the Yum’s, the number of plugins increasing, the API expanding and the Anaconda integration steadily improving, it is about time to say what is meant by “DNF”, the abbreviation.

To start from the start: Yum originally stood for “Yellowdog Updater Modified”. A colleague of ours thought “hawkey” would be a cool name for a new packaging project, in a random way continuing “Yum” since his yellow-coated pet dog’s name was Hawkey. So that’s how the lib got its name. Now that is near Hawkeye, the M*A*S*H character. So we picked a name expressing some continuation from the previous tool and expressing the new tool is Hawkeye Pierce-dandier by having hawkey embedded in it:

Dandified Yum, “DNF” in short and “dnf” on the command line.[1]

Anybody out there: if you are willing to contribute a Creative Commons logo now that the full name is known, please leave one with your name and email address in the comments and if we find it lovely we’ll get in touch with you.

[1]We also briefly considered calling the forked Yum “BJ”, like Hawkeye’s colleague. That got turned down fast.

DNF 0.4.17 Released

After a week’s development sprint we are back with a new version today.

It was an unfortunate side-effect of the refactorings in 0.4.15 that DNF users of the two last releases sometimes experienced crashes and garbled output during the download phases. This release contains a long list of fixes for those, along with extensions to help us chase similar problems in the future.

There are new API calls in the repo management department and a bug fixed that prevented many from using --cacheonly. Linking to the release notes.

Behind the scenes a lot of work is going into reimplementation of repo-pkgs command from Yum. With repo-pkgs, but also other commands, we are often having a hard time determining which subcommands are legacy and which are used/have use cases. Users’ insights on this problem would be welcome, i.e. we’d be really interested to know what you think is worth dropping and why.