I personally like yum as well
Posted Dec 2, 2003 3:22 UTC (Tue) by niemeyer
In reply to: I personally like yum
Parent article: New features in APT-RPM
First, let me position myself. I'm not against yum. I do like the idea of someone working on a completely different implementation, and I'd really like to see yum evolving. Also, I'm a big Python fan, being even one of the contributors of the core language, as you can see in my (wiki|web)log and my projects page.
"Having to download all that rpm header is sure painful but it lets yum use librpm for dependency handling locally."
APT-RPM meta-information is also based on rpm headers. OTOH, unuseful information in that context is stripped when the "pkglist" (AKA. header list) is created.
"Also note that apt-rpm is implemented in C and it has to make a
special effort to "export" its functionality to the lua scripting
APT-RPM is implemented in C++, and the important thing about the
Lua extension is not the effort I've done to implement it, but how
it satisfy users needs.
"The lua code looks quite nice, though a bit too imperative since
most people are used to writing filters under the unix shell?"
I don't understand this point. You seem to like the fact that yum is written in Python (as I do).
"While yum is implemented in python utilizing the same python bindings to rpm etc used by the Redhat system management tools."
And APT-RPM is implemented using the C bindings used by every distribution using the RPM API, including the python bindings. Indeed, I belive APT-RPM is the only software today supporting the API of RPM version 3.0.X, 4.0.X, 4.1.X, 4.2.X, and CVS.
"IMHO, programs like yum or apt-get shouldn't be implemented in C."
Agreed. I'd be glad if APT was implemented in Python, but it isn't.
I think the apt-rpm functionality is quite impressive but the difficulty in merging the debian,apt-rpm and Progeny trees is only complicated when the code is in 40000 lines of C instead of 5000 lines of python.
Today, Michael Vogt has sent me a patch of 12kb which makes APT-RPM work in Debian. Also, the APT-RPM port has always been up-to-date with the changes done in the Debian APT, as was written in the article. Progeny is one more in the merging group, and is very welcome. Debian has a slower merging politic, but is merging changes from APT-RPM and Progeny as well.
About the number of lines, I'm sorry, but I don't understand why you belive that this information is relevant, since they have a different set of features and Yum will need a considerable amount of work to get where APT-RPM currently is. Of course, it will still have less lines of code
if it ever get into the APT-RPM stage, since it's implemented in Python, but that's not the case right now.
to post comments)