[Catalog-sig] PyCon sprint for PEPs 314 and 243?
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
> 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
> 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
>> 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
> problem as some people seem to think. Red Hat and Debian have fairly
> 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
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