Mageia To Offer DNF, But Will Keep Using URPMI By Default

[phoronix]

Phoronix: Mageia To Offer DNF, But Will Keep Using URPMI By Default

The RPM-based Mageia Linux distribution has decided to offer Fedora's DNF forked version of Yum in their next major release...

http://www.phoronix.com/scan.php?pag...o-Have-DNF-Yum

[GreatEmerald]

Interesting, I wonder why not the zypper/OBS combination. OBS already supports Mageia IIRC.

[King InuYasha]

Interesting, I wonder why not the zypper/OBS combination. OBS already supports Mageia IIRC.

Hey, I'm the guy who actually is implementing all of this.

The most compelling reason to choose DNF was the API. It's not that easy to integrate Zypper into applications written in languages other than C++, whereas DNF has a Python API (by virtue of being written in Python) and someone has written a daemon that lets us use it via the API in non-Python applications. The Zypper bindings are very flaky and mostly not usable. Most of Mageia's tools are written in Perl and Python, so this is an important consideration. Even without that, the underlying libraries that DNF uses are written in C, and are easy enough to access from other languages through gobject-introspection or a CFFI. The PackageKit-Hif backend is also more reliable in my experience. And unlike Zypper, there's a non-YaST GUI frontend already available for us to use while we update our own, if we want to use it.

There are also a couple of features in DNF that don't exist in Zypper that we want to leverage:

• Actionable history (dnf history info/list/undo/redo)
• Programmable transaction hooks

Using DNF doesn't preclude OBS integration. In fact, if an OBS plugin were to be written for DNF, it would just work with Mageia 6, because I've already worked with the OBS guys to prepare for it.

[mo0n_sniper]

I was also wondering why dnf was choosen because as a sysadmin I find using zypper way cooler. Didn't know about the programming situation.
Good luck with you implemntation and maybe you could also have a look at zypper. There is a copr for zypper in fedora.

And may this be a step in the right direction for unifing software packages on Linux...one day...maybe

[King InuYasha]

I was also wondering why dnf was choosen because as a sysadmin I find using zypper way cooler. Didn't know about the programming situation.
Good luck with you implemntation and maybe you could also have a look at zypper. There is a copr for zypper in fedora.

And may this be a step in the right direction for unifing software packages on Linux...one day...maybe

I know about the Zypper copr repo in Fedora, as it's mine.

I originally created it so that I could experiment with Zypper and see which one I wanted to put my energy towards.

Zypper does have some nice things, like the colorful text, which makes it easier to identify the kind of changes occurring. It'd be nice to see that in DNF, too.

[andreano]

Some things I miss in dnf:
* Equivalents of zypper se -s and zypper se -si (shows detailed package info as a table, -i shows only installed packages)
* zypper ps (shows which processes need restarting after an upgrade)

[andreano]

zypper is way cooler.

Agree!

Too bad the bindings were flaky…

[King InuYasha]

Some things I miss in dnf:
* Equivalents of zypper se -s and zypper se -si (shows detailed package info as a table, -i shows only installed packages)
* zypper ps (shows which processes need restarting after an upgrade)

There is a plugin to implement the equivalent of "zypper ps". If you install "dnf-plugins-extras-tracer", you'll get that capability through the tracer plugin.

Feel free to contribute a plugin to offer the equivalent of "zypper se -s", as the project is on GitHub!

[mo0n_sniper]

I know about the Zypper copr repo in Fedora, as it's mine.

small world

Do you think that using the fedora repositories with zypper could be fixed to be used withouth modifications.
If I'm not mistaken that was one of the points for not having it included in fedora.

[King InuYasha]

small world

Do you think that using the fedora repositories with zypper could be fixed to be used withouth modifications.
If I'm not mistaken that was one of the points for not having it included in fedora.

I think so. I've filed a bug for it in the Red Hat Bugzilla. The other requirement is libsolv having additional features switched on at build-time. The change has been made to the package, but it hasn't yet been submitted as an update to the Fedora repos.