Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
What is the point of this article?
New features in APT-RPM
Posted Dec 2, 2003 0:23 UTC (Tue) by snitm (guest, #4031)
I personally like yum
Posted Dec 2, 2003 2:30 UTC (Tue) by scottt (subscriber, #5028)
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 language,even embedding the lua interpreter.(The lua code looks quite nice, though a bit too imperative sincemost people are used to writing filters under the unix shell ?)While yum is implemented in python utilizing the same python bindings to rpm etc used by the Redhat system management tools.All the functionality in yum is thus available to a python literate sysadmin with no extra effort.IMHO, programs like yum or apt-get shouldn't be implemented in C.
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.
I personally like yum as well
Posted Dec 2, 2003 3:22 UTC (Tue) by niemeyer (guest, #17169)
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.
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.
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.
I don't understand this point. You seem to like the fact that yum is written in Python (as I do).
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.
Agreed. I'd be glad if APT was implemented in Python, but it isn't.
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.
Posted Dec 2, 2003 4:48 UTC (Tue) by scottt (subscriber, #5028)
First I would like to thank you personally for your python contributions.
I was just using the bz2 module at work yesterday.
I didn't recognize your name until I read your projects page.
My comments about the extra effort to support lua and the code size of apt-rpm is really just another way to say I think C/C++ is not the best choice for an implementation language in this case.
Though 40000 lines isn't large for a C++ project, complexity still has its cost.The python culture favors C/C++ libraries having python bindings instead of embedding an interpreter in a C/C++ app for a reason.
About the lua code being too "imperative", what I ment was perhaps using a more "functional" style with "iterators" and "map" etc,
instead of for-loops and "markinstall".
ie. install_devel() in python using an imaginery library:
for p in pkgs:
return [ p for p in dev_pkgs(uptodate_packages())
if not p.is_uptodate() ]
map(lambda p: p.install(),devel_packages_to_install())
As you can see I'm dying for generator comprehensions ;)
By the way, does lua have a standard iterator/lazy-list interface?
Posted Dec 2, 2003 5:10 UTC (Tue) by niemeyer (guest, #17169)
About the "imperativeness", I understand. Lua syntax is indeed a little bit more limited. OTOH, that's expected in a language for embedded environments.
About Lua iterators, yes, the generic 'for' loop allows the underlying function to provide data step-by-step. Lua also implements coroutines, which are the counterpart of Python's generators. For more information, please, check the Lua manual.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds