CPAN functionality for python

[Sean Reifschneider]

On Mon, Feb 12, 2001 at 09:03:39PM +0000, ssthapa at classes.cs.uchicago.edu wrote:
>  I'm not familiar with Trove, what is it? It would be difficult 

Seems based on Eric's response that you need to use "was" instead of "is".
It was meant to be a large software catalog, originally meant to replace
the mirrors of Sunsite.

>to integrate this system with dkpg, or rpm.  At the very least, it 

Being a catalog means that it doesn't have to interfere with dpkg or
rpm.

>  I've taken some of CPAN's ideas as inspiration while writing my code
>but I'm not sure how much more help CPAN can be outside as being an example
>of a similar system.

The architecture I see is (simplified):

	A package has one or more versions.
	A version has one or more flavors.
	A flavor has one or more locations.

A package identifies the name and other attributes of the software.  The
version identifies the revisions.  The flavor would identify:

	Packaging format (tar, SRPM, dpkg, Distutils)
	Architecture (any, i386, alpha)
	Platform (any, RedHat, Debian, Windows)
	PlatformVersion (any, 7.0, 2.2, 3.11)

So that way a user can set preferences:

	I'd prefer to get an SRPM to have built on my box.  If there isn't one of
	those, snag a binary RPM for RedHat 7.0.  Ok, then I'd try installing from
	Distutils, and if all else fails give me the tar file and I'll try building
	from that.

It doesn't preclude dpkg, it embraces it.  IMHO, a requirement.

>  Parts of this are already implemented, e.g. the config file lists 
>a group of mirrors and the script will try to grab the file from one and will
>move on to the next if its connection is refused.  I guess an extension to 
>this would be randomize which server is choosen or to allow the mirrors
>to have preferences associated with them.  However, at the moment the 

Personally, I think that's more a mirror decision than something that should
be put in the catalog.  If I've got a list of 10 mirrors for a file, it would
be nice to send them a UDP packet asking if how willing they are to serve
a file.  Their willingness depends highly on the time of day and other
factors that you can't predict ahead of time (going to a host that has a
RedHat mirror is going to suck the day that they announce 7.1, eh).

Really, most of the mirror selection should probably be done by the client
software.  It'd be especially cool if the client could ask it's squid proxy
if it had any of the URLs cached...

>  With a conventional ftp client,  this is sort of doable.  If you let
>administrators place a dummy file in the archive that indicates that this
>mirror is overloaded, then you can get a crude way of skipping loaded servers.

Well, they usually do that by spitting out a file that says "I'm busy, go
away", and then you're off to search for another mirror.  Not very
effective, and rather heavy-weight.  Ideally, the client would send a UDP
packet to all the mirrors saying "Hey, I want this file", the mirrors
would receive it, maybe delay responding if they were loaded, drop it if
they were heavily loaded, and respond with a willingness level if they
have it and are up to sending it.  The first reply the client gets is
likely to be the best choice for trying to get a response from, especially
if servers make an effort to delay the response an appropriate period of
time based on the mirror load.

Sean
-- 
 "All I'm saying is that when I'm around you I find myself showing off,
 which is the idiots version of being interesting."  -- _LA_Story_
Sean Reifschneider, Inimitably Superfluous <jafo at tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python