RPM roadmapping

Florian Festi ffesti at redhat.com
Tue Jul 31 11:58:04 UTC 2007


Rahul Sundaram wrote:
> Robert Scheck wrote:
>> Hello Rahul,
>>
>> On Tue, 31 Jul 2007, Rahul Sundaram wrote:
>>> Pyrpm is described as "PyRPM is an experimental project to look at 
>>> rpm package management". It is a prototyping tool. Not a 
>>> implementation meant to be used by users currently unlike Yum (which 
>>> I think is what you are referring to as pyyum).
>>
>> okay, you did never use PyRPM.
> 
> I don't know why you want to assume that.  My use is irrelvant to your 
> question on whether pyrpm duplicates yum and RPM.  Answer: No. it 
> doesn't. pyrpm is clearly described as a experimental prototype in it's 
> homepage at http://www.jur-linux.org/pyrpm/. That's the first hit in 
> google btw.

Your use is relevant when it comes to the question if your opinion is in any 
way better founded than that of google.

> It is called yum and not pyyum which would a redundant name since the 
> only existing implementation of Yum is in python. If you are a Fedora 
> user, the fact the name is yum should have been obvious.

The PyRPM suite includes pyrpm - a rpm replacement in pure Python, pyrpmyum 
  - a yum reimplementation build on top of the pyrpm libs, pyrpmkickstart - 
a tool for doing kickstart installations from within a running system into 
hard drives or disk images. There are also a number of test scripts  for 
checking rpm based distributions for various problems.

The whole software suite is written from scratch in pure Python. This was 
done to be independent from upstream projects (rpm, yum) and to be a rapid 
prototyping testbed for experimental and/or new features/modifications. It 
also provides a basis for various large scale tests that were either too 
complicated or simply not doable with the existing tools.

It was (and to some extend still is) experimental in the sense of

1. Developing/using advanced techniques not (yet) found in rpm and yum. This 
includes better multilib handling, auto eraser, better depsolving, high 
performance and low memory foot print. I am just now porting the first 
lessons learned there to yum.

2. Not having a large enough user base to be considered as stable. Due to a 
large number of tests we have done with that codebase we're now quite 
confident that we have at least reached a similar stability as the current 
version of yum.

I hope that makes things more clear.

Florian




More information about the fedora-devel-list mailing list