[Catalog-sig] PyCon sprint for PEPs 314 and 243?

Bob Ippolito bob at redivi.com
Sun Jan 16 01:53:51 CET 2005

On Jan 15, 2005, at 19:23, Sean Reifschneider wrote:

> On Fri, Dec 31, 2004 at 08:28:35PM +1100, Richard Jones wrote:
>> Without looking into it too closely, it seems like yum is closely 
>> tied to RPMs
>> and their associated package databases.
> I would suspect that the code for handling mirror lists and 
> downloading of
> files is not at all tied to the RPM file format.  That code has had
> something like a year of development on it, and probably can be used 
> with
> few changes.

Well, yum is GPL and therefore not suitable for inclusion into Python.  
It doesn't really matter if the code is already written in Python and 
implements some useful things, unless you're certain that you can get 
those components relicensed to suit Python.

> There are 3 different downloaded file types: RPM packages, RPM 
> headers, and
> the repository information.  The repository information would probably
> require some tweeks, and the RPM packages and headers would need to be
> replaced with something else.  Unless we were to decide to use RPM as 
> the
> package format.  Which is probably also not a bad idea.

Is the RPM format itself well specified?  Is there already a suitably 
licensed pure Python implementation for creating and using RPM files?  
Platforms that don't already have RPM are going to need it, and I 
believe that librpm is GPL (and probably also not portable everywhere 
Python is), so we couldn't add that dependency for an extension to wrap 
this functionality.

>> Also, I'm not sure I want to try to solve dependencies.
> I'm not sure you have a choice not to.  I'm also not sure it's as hard 
> a
> problem as some people seem to think.  Red Hat and Debian have fairly 
> good
> solutions to this problem with years and years of thought behind them.

Dependency tracking and resolution requires package maintainers.  I 
think we'd be better off deferring the implementation of this, because 
it would take more effort to get this solution out the door and it 
would require an additional burden to make these packages.  If PyPI had 
tried to solve packaging, distribution, dependency tracking, etc. from 
the start, it would've never finished.

I don't think Python is really ready for this kind of system anyway.  
I'd rather try and fix the fundamental problems of versioning and 
module namespaces in Python itself (which are probably 90% policy and 
10% implementation).

I also find the Red Hat / Debian solution to *this* issue quite 
obnoxious in that you often have to install or upgrade more packages 
than should be necessary.


More information about the Catalog-sig mailing list