| |||||||||||||
New features in APT-RPMNew features in APT-RPMPosted Dec 2, 2003 0:23 UTC (Tue) by snitm (guest, #4031)In reply to: New features in APT-RPM by dmantione Parent article: New features in APT-RPM
Um, how about... to inform people of the really useful features that APT-RPM has to offer beyond Debian's APT. APT-RPM is a great tool; YUM is really slow. Making yum-users APT-aware is a good thing.
(Log in to post comments)
I personally like yum Posted Dec 2, 2003 2:30 UTC (Tue) by scottt (subscriber, #5028) [Link] In yum's defence, it's not that the program is slow so mush as it assumes you have a fat pipe to the yum repository. This probably works well in an university environment where each department can offer a local repository server for its special packages but less well over the internet.Having to download all that rpm header is sure painful but it lets yum use librpm for dependency handling locally. 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, 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) [Link] 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. Now... "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 language"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.
I personally like yum as well Posted Dec 2, 2003 4:48 UTC (Tue) by scottt (subscriber, #5028) [Link] 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:
def devel_packages_to_install():
def dev_pkgs(pkgs):
for p in pkgs:
try:
yield package(p.name+'-deve')
yield package(p.name+'-deve-static')
except:
pass
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?
I personally like yum as well Posted Dec 2, 2003 5:10 UTC (Tue) by niemeyer (guest, #17169) [Link] 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.
|
|||||||||||||