Fedora's DNF Is Slowly Being Ported From Python To C

[phoronix]

Phoronix: Fedora's DNF Is Slowly Being Ported From Python To C

Fedora's DNF package manager that succeeded Yum officially in Fedora 22 is going to go through a phase of being rewritten in C...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-DNF-Python-To-C

[Luke_Wolf]

So much effort for Red Hat to be able to say "It's not zypper"...

[rabcor]

But why?! DNF is fine as it is... yum-extender is not (neither the old one nor the DNF linked one), but DNF definitely is...

If it ain't broken, dont't fix it, if it's working, don't go breaking it without good reason!

[stephen82]

If performance is their major concern, why haven't tried to rewrite the "slow" parts to Cython or something similar that transcompiles to C or C++11 / C++14 and use that kind of logic instead?

Also, I can see from the code that they use Glib. If they wanted to use Standard Libraries, why they didn't go with C++11 in the first place and take advantage of the existing set of well-known libraries that could be used and produce a faster output or use PyPy instead?

I really want to know what's the actual excuse behind this decision.

[dh04000]

Wow.... screw this community. I remember the constant groaning and bitching that Canonical using python for USC and other ubuntu specific apps. Complaints that python was slow and that they were idiots from ever using it. In comparison, people were practical losing their minds in excitement over DNF, which turns out uses python! Why no complaints there? The double standards are amazing in this community.

[starheap]

Reading through the blog post this is more about having consistency across multiple package management frontends rather than performance.

[Luke_Wolf]

Wow.... screw this community. I remember the constant groaning and bitching that Canonical using python for USC and other ubuntu specific apps. Complaints that python was slow and that they were idiots from ever using it. In comparison, people were practical losing their minds in excitement over DNF, which turns out uses python! Why no complaints there? The double standards are amazing in this community.

We all know you're pretty much Mark Shuttleworth or a shill of his, but don't misrepresent the facts of what was going on, there was quite a bit of strife over the yum to DNF transition, particularly once they announced that their claimed reason for not just using zypper instead of going to all the trouble of developing a new package manager based upon libZypp was no longer going to be upheld. Rewriting DNF in C just makes their claimed reasoning all the less valid.

[dh04000]

We all know you're pretty much Mark Shuttleworth or a shill of his.

Best laugh of the day. Thank you Luke.

[birdie]

I wonder when DNF will get back this crucial feature every other package manager has:

https://bugzilla.redhat.com/show_bug.cgi?id=1148627

Sometimes I feel like the disease of oversimplification of everything to the point of making it unusable has established itself among open source developer as well.

[rabcor]

Wow.... screw this community. I remember the constant groaning and bitching that Canonical using python for USC and other ubuntu specific apps. Complaints that python was slow and that they were idiots from ever using it. In comparison, people were practical losing their minds in excitement over DNF, which turns out uses python! Why no complaints there? The double standards are amazing in this community.

Wait who was hyped over DNF again? It was more like nobody cared, much like nobody really cares that DNF is being ported to C, in fact in both cases... no one even gets "why?!"

And to be honest, I'm guessing the real answer to that is "we wanted to, so we did it. Do we need a reason?"