From s-thapa-11@alumni.uchicago.edu Sat Sep 1 15:49:17 2001
From: s-thapa-11@alumni.uchicago.edu (Suchandra Thapa)
Date: Sat, 1 Sep 2001 09:49:17 -0500
Subject: [Catalog-sig] Status
In-Reply-To: <057001c12bf3$5c653b30$ae03a8c0@activestate.com>; from andym@ActiveState.com on Thu, Aug 23, 2001 at 09:47:53AM -0700
References: <057001c12bf3$5c653b30$ae03a8c0@activestate.com>
Message-ID: <20010901094917.C1623@hepcat>
--0vzXIDBeUiKkjNJl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Aug 23, 2001 at 09:47:53AM -0700, Andy McKay wrote:
> Just wondering what the status of the catalog-sig, whats the plan for mov=
ing
> forward, and what can I do to help?
>=20
> Looking at the status it looks like we had two prototypes one in Zope (li=
nk
> not working) and another that I havent looked at installing yet. But after
> that activity seems to have stopped...
>=20
I have some code that has limited functionality. Currently it
has a text interface, has a basic system for specifying package and server
information, can deal with dependencies, and there is currently some ftp
code but I haven't tested that yet. I've been meaning to work on it but=20
have gotten busy earlier. I need to add more documentation and change some
of the code around to make it easier to understand. I'm in the midst of mo=
ving
but I should get some time to put some work on it later, and should be able=
to
post an alpha version here on Tuesday, possibly earlier. =20
The biggest problem I came across when writing the code was a lack of a=
=20
catalog for locating information about installed packages. Without that it=
=20
becomes very difficult to handle dependencies in more than a rudimentary=20
fashion. I know this was discussed on the distutils sig but I'm not sure w=
hat=20
the current status on this is. Also a listing of files in a package would be
important if we want to let users delete packages but is not necessarily (C=
PAN
current seems to do okay without a delete function).
The other area we problem need to consider is package maintenance on sy=
stems
that have a package manager. I believe distutils allows you to generate rp=
ms
from a package so it should be too difficult to integrate this with rpm bas=
ed
distributions. I don't think other package formats like debian or slackware
are support by distutils so it would be more difficult to integrate into t=
hose
systems. =20
Also I'm not sure how well windows could be supported. Pure python=20
packages shouldn't be a problem but packages that have c or c++ files to be
compiled would probably need to be distributed as a binary since gcc, vc++,=
=20
and/or swig probably won't be available. How does disutils work on windows?
=20
--=20
------------------------------------------------------------------
Suchandra S. Thapa=20
s-thapa-11@alumni.uchicago.edu
------------------------------------------------------------------
--0vzXIDBeUiKkjNJl
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjuQ9WwACgkQ6nShCjt5AZIc9ACfQ6M6yCZWCVVUBM4Z4/NwAZJf
xEsAoIje+hbyKdHivJad84qm7VTwNuH6
=PQnx
-----END PGP SIGNATURE-----
--0vzXIDBeUiKkjNJl--
From martin@loewis.home.cs.tu-berlin.de Sun Sep 2 16:54:34 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Sun, 2 Sep 2001 17:54:34 +0200
Subject: [Catalog-sig] Status
In-Reply-To: <012c01c12ccb$e7128b60$ae03a8c0@activestate.com>
(andym@ActiveState.com)
References: <057001c12bf3$5c653b30$ae03a8c0@activestate.com> <200108231918.f7NJIMs07607@odiug.digicool.com> <00ce01c12c28$04485dd0$ae03a8c0@activestate.com> <200108240102.VAA02194@cj20424-a.reston1.va.home.com> <012c01c12ccb$e7128b60$ae03a8c0@activestate.com>
Message-ID: <200109021554.f82FsYu04691@mira.informatik.hu-berlin.de>
> Probably, what I need is a vision. I havent got one yet.
Then just take mine :-) "Make the registry for Python packages
operational for production use".
I'd like to see the registry operate somewhere at python.org, but that
is not mandatory - what matters more is some sort of guarantee that
data put in won't be lost, and that there are no downtimes of the
service longer than, say, 24h.
It may be that it won't be used once it is there; in this case, I can
offer the follow-up vision "talk <pick some number> package
maintainers into putting their software into the registry, and to
update the entry every time they update the package".
These people would be "early adaptors", so you not only have to talk
them into using the system, but also to deal with all the problems
they find.
Regards,
Martin
From andym@ActiveState.com Mon Sep 3 18:29:07 2001
From: andym@ActiveState.com (Andy McKay)
Date: Mon, 3 Sep 2001 10:29:07 -0700
Subject: [Catalog-sig] metadata
References: <20010831183938.51696.qmail@web11608.mail.yahoo.com>
Message-ID: <00a001c1349d$f0374b70$ae03a8c0@activestate.com>
> I spent some time looking at the metadata of some
> other packaging systems namely Debian's apt, ACS's
> apm, and the OSD format.
Yep, we use the OSD format quite well in the perl and python packager
manager.
> there is also an assumption within the pep241 and 243
> i'd like to address. namely that the author of a
> package will be the person to upload a package. at
> least initially this is likely to be unlikely,
> especially during an initial rush to fill up the
> repository via some semi-automated extraction from the
> vaults.
You're absolutely right, this was an issue we had with our catalog.
> something else i was considering is a some type of
> global unique identifier to allow for replication of
> information to different repositories. i was thinking
> of something along the lines of a new uri protocol
> that identified a package on the basis of its
> classification with the catalog... i'm a little fuzzy
> on this.
You probably dont want to make it unique on the classification since that
may change. CPAN uses
authors, which isn't too bad but we will be a little less strict on that.
Wouldn't the combination
of package name and version be good enough and reasonably permanent?
Cheers.
--
Andy McKay.
From guido@python.org Tue Sep 4 01:06:44 2001
From: guido@python.org (Guido van Rossum)
Date: Mon, 03 Sep 2001 20:06:44 -0400
Subject: [Catalog-sig] Status
In-Reply-To: Your message of "Sun, 02 Sep 2001 17:54:34 +0200."
<200109021554.f82FsYu04691@mira.informatik.hu-berlin.de>
References: <057001c12bf3$5c653b30$ae03a8c0@activestate.com> <200108231918.f7NJIMs07607@odiug.digicool.com> <00ce01c12c28$04485dd0$ae03a8c0@activestate.com> <200108240102.VAA02194@cj20424-a.reston1.va.home.com> <012c01c12ccb$e7128b60$ae03a8c0@activestate.com>
<200109021554.f82FsYu04691@mira.informatik.hu-berlin.de>
Message-ID: <200109040006.UAA04435@cj20424-a.reston1.va.home.com>
> > Probably, what I need is a vision. I havent got one yet.
>
> Then just take mine :-) "Make the registry for Python packages
> operational for production use".
Exactly.
> I'd like to see the registry operate somewhere at python.org, but that
> is not mandatory - what matters more is some sort of guarantee that
> data put in won't be lost, and that there are no downtimes of the
> service longer than, say, 24h.
I can't talk for XS4ALL, but I expect that this won't be a problem.
> It may be that it won't be used once it is there; in this case, I can
> offer the follow-up vision "talk <pick some number> package
> maintainers into putting their software into the registry, and to
> update the entry every time they update the package".
>
> These people would be "early adaptors", so you not only have to talk
> them into using the system, but also to deal with all the problems
> they find.
I doubt that finding early adopters would be a problem. Dealing with
the problems they find is of course essential for the success.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From martin@loewis.home.cs.tu-berlin.de Wed Sep 5 08:01:21 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Wed, 5 Sep 2001 09:01:21 +0200
Subject: [Catalog-sig] metadata
In-Reply-To: <20010831183938.51696.qmail@web11608.mail.yahoo.com> (message
from Kapil Thangavelu on Fri, 31 Aug 2001 11:39:38 -0700 (PDT))
References: <20010831183938.51696.qmail@web11608.mail.yahoo.com>
Message-ID: <200109050701.f8571Lr01769@mira.informatik.hu-berlin.de>
> I've started work on a fourth catalog implementation.
> I've had a few questions/comments, i wanted to send to
> the list to resolve regarding metadata.
While this is a laudable goal, I have a few procedural concerns with
your message.
> the key for interoperability among the three is having package
> metadata.
More specific, the key for interoperability is having *standard*
metadata.
> looking over pep 241, i can note several deficiencies
> that i would like to address. While the use of rfc822
> for metadata definition does lower the author burden
> is unextensible and creates the opportunity for
> ambiguity in the metadata, i'd like to change this to
> an xml based format.
This is where my procedural concerns start. PEP 241, as-is, is already
implemented in distutils and currently available to users through
Python 2.2aX. Any change at this point in time needs a *very* good
reason for the change, such as the PEP being unimplementable, not
achieving the goal it is intended to achieve, etc.
IOW, changing the format of the metadata now will significantly slow
down progress on producing a catalog implementation, and getting
packages registered with it. Thus, we might get the perfect system on
paper; I'd rather prefer an incomplete system in reality.
As for XML specifically: What problem does the mere switching to XML
achieve? I believe your claim that the current format is unextensible
is incorrect: The Metadata-Version was put in precisely to allow
future extensions. I'd strongly discourage "proprietary" extensions at
this time, so not being able to put in those is a good thing: Any
extensions used ought to be published and documented, in a revision of
PEP 241.
> probably the biggest problem with adoption of pep241
> is the lack of dependency info. Dependency info should
> be both version specific and capable of being os
> dependent.
Because package dependency is really hard, I believe it was
deliberately left out from version 1.0 of the metadata. That means
that any package author requiring prerequisite packages should put the
prerequisite list into the Description, with the user of the catalog
being responsible for fulfilling the prerequisites.
So lack of dependency info is IMO a key to success, rather than a
problem.
> there is also an assumption within the pep241 and 243
> i'd like to address. namely that the author of a
> package will be the person to upload a package. at
> least initially this is likely to be unlikely,
> especially during an initial rush to fill up the
> repository via some semi-automated extraction from the
> vaults.
That's a good point. Should we support a Packager field in addition to
the Author field (which, of course, requires a new Metadata-Version)?
Alternatively, would could encourage uploaders to put their name into
the Author field, and put the "true" author into the Description. I
doubt the true author would be happy to receive complaints about the
packaging when she didn't even know somebody uploaded the package.
That also relates to the question how package uploads get approved;
that is something that whoever operates the catalog needs to find a
policy for. E.g. some uploaders could get permission to upload
packages they didn't author (you can find out the signer of a package
from the signature, right?)
> i'll try and write up an xml schema which defines this
> package-metadata xml format.
Before you do so, I'd like to hear more what problems you expect to be
solved by an XML format over the PEP 241 format.
Regards,
Martin
From rnd@onego.ru Wed Sep 5 18:03:33 2001
From: rnd@onego.ru (Roman Suzi)
Date: Wed, 5 Sep 2001 21:03:33 +0400 (MSD)
Subject: [Catalog-sig] Status
In-Reply-To: <200109040006.UAA04435@cj20424-a.reston1.va.home.com>
Message-ID: <Pine.LNX.4.30.0109052059130.23052-100000@rnd.onego.ru>
On Mon, 3 Sep 2001, Guido van Rossum wrote:
>> It may be that it won't be used once it is there; in this case, I can
>> offer the follow-up vision "talk <pick some number> package
>> maintainers into putting their software into the registry, and to
>> update the entry every time they update the package".
Can't SourceForge infrastructure used for managing Python Catalog? This
will solve many problems, as many packages are at home at SF anyway. So
they could do it virtually linking entries into Catalog (without stroing
thing double). Just an idea... I really do not know what SF _can_.
>> These people would be "early adaptors", so you not only have to talk
>> them into using the system, but also to deal with all the problems
>> they find.
>
>I doubt that finding early adopters would be a problem. Dealing with
>the problems they find is of course essential for the success.
Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd@onego.ru _/
_/ Wednesday, September 05, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "... Clinton sandwich: $5 of baloney and $20 in taxes" _/
From mats@laplaza.org Thu Sep 6 08:45:26 2001
From: mats@laplaza.org (Mats Wichmann)
Date: Thu, 06 Sep 2001 03:45:26 -0400
Subject: [Catalog-sig] Status
In-Reply-To: <Pine.LNX.4.30.0109052059130.23052-100000@rnd.onego.ru>
References: <200109040006.UAA04435@cj20424-a.reston1.va.home.com>
Message-ID: <5.1.0.14.1.20010906033600.0453f108@204.151.72.2>
>Can't SourceForge infrastructure used for managing Python Catalog? This
>will solve many problems, as many packages are at home at SF anyway. So
>they could do it virtually linking entries into Catalog (without stroing
>thing double). Just an idea... I really do not know what SF _can_.
Dunno, but I'll take a look at it sometime. I had suggested in
a different forum that we maybe needed a site for little packages,
that were not big enough for their own SF projects...some of those
maybe coming out of the now deleted "contrib" directory from
python.org. Tim Peters suggested setting up a single SF project as
a container for all these smaller bits. Don't know well this
would work without exploring further.
From guido@python.org Thu Sep 6 10:32:12 2001
From: guido@python.org (Guido van Rossum)
Date: Thu, 06 Sep 2001 05:32:12 -0400
Subject: [Catalog-sig] Status
In-Reply-To: Your message of "Thu, 06 Sep 2001 03:45:26 EDT."
<5.1.0.14.1.20010906033600.0453f108@204.151.72.2>
References: <200109040006.UAA04435@cj20424-a.reston1.va.home.com>
<5.1.0.14.1.20010906033600.0453f108@204.151.72.2>
Message-ID: <200109060932.FAA01263@cj20424-a.reston1.va.home.com>
> Dunno, but I'll take a look at it sometime. I had suggested in
> a different forum that we maybe needed a site for little packages,
> that were not big enough for their own SF projects...some of those
> maybe coming out of the now deleted "contrib" directory from
> python.org. Tim Peters suggested setting up a single SF project as
> a container for all these smaller bits. Don't know well this
> would work without exploring further.
Another alternative would be to revive use of the starship.python.net
site for this.
--Guido van Rossum (home page: http://www.python.org/~guido/)
From k_vertigo@yahoo.com Fri Sep 7 06:24:42 2001
From: k_vertigo@yahoo.com (Kapil Thangavelu)
Date: Thu, 6 Sep 2001 22:24:42 -0700 (PDT)
Subject: [Catalog-sig] metadata
In-Reply-To: <200109050701.f8571Lr01769@mira.informatik.hu-berlin.de>
Message-ID: <20010907052442.35461.qmail@web11603.mail.yahoo.com>
--- "Martin v. Loewis"
<martin@loewis.home.cs.tu-berlin.de> wrote:
> > I've started work on a fourth catalog
> implementation.
> > I've had a few questions/comments, i wanted to
> send to
> > the list to resolve regarding metadata.
>
> While this is a laudable goal, I have a few
> procedural concerns with
> your message.
allright.
> > the key for interoperability among the three is
> having package
> > metadata.
>
> More specific, the key for interoperability is
> having *standard*
> metadata.
definitely.
>
> > looking over pep 241, i can note several
> deficiencies
> > that i would like to address. While the use of
> rfc822
> > for metadata definition does lower the author
> burden
> > is unextensible and creates the opportunity for
> > ambiguity in the metadata, i'd like to change this
> to
> > an xml based format.
>
> This is where my procedural concerns start. PEP 241,
> as-is, is already
> implemented in distutils and currently available to
> users through
> Python 2.2aX. Any change at this point in time needs
> a *very* good
> reason for the change, such as the PEP being
> unimplementable, not
> achieving the goal it is intended to achieve, etc.
the pep is obviously implementable, the question is
rather does it achieve its goal, the pep itself
doesn't define a goal, so that is hard to say.
as for achieving my goal as stated previously as
"""
creating a pythonic version of cpan/apt, to automate
installation of new packages with depedency
resolution.
"""
the pep as it currently stands make such a goal IMO
pratically unattainable/maintainable.
therefore the sooner changes are discussed and made,
the better.
> IOW, changing the format of the metadata now will
> significantly slow
> down progress on producing a catalog implementation,
> and getting
> packages registered with it. Thus, we might get the
> perfect system on
> paper; I'd rather prefer an incomplete system in
> reality.
two things, regarding slowing down catalog
implementations, i think changing the format of the
metadata so that it can achieve the above goal, will
affect just the opposite, namely to speed up catalog
development by providing standard metadata needed to
provide the interfaces suggested in the catalog-sigs
in addition to additional services like subscriptions
and syndication.
second, please understand that it is not my desire to
mandate any changes to existing peps or guidelines. i
want to create a real world extensible system that can
be used and tested before asking for pep revisions and
or authoring new peps , as per my interpretation of
pep guidelines from pep 1
"""
The PEP should be reviewed and accepted before a
reference implementation is begun, unless a reference
implementation will aid people in studying the PEP.
"""
i intend to conduct development openly in this forum
with key draft documents available for review. i
sincerely want to have a real world implementation
that can be adapted to existing standards and allow
for open implementations of a client (for example an
rdf based client). what i've stated in my metadata
comments reflect my thoughts on an information set
that i will be using internal to the server and
client. making this infoset standard will ease both
development and maitainenace. if upon completion of
this catalog server these changes are ill-recieved i
can hack up some conversion. the server should also
allow manual addition of such information via web
interfac. also a real world implementation fufills the
original comments to the recent 'status' thread for an
implementation as well.
> As for XML specifically: What problem does the mere
> switching to XML
> achieve? I believe your claim that the current
> format is unextensible
> is incorrect: The Metadata-Version was put in
> precisely to allow
> future extensions. I'd strongly discourage
> "proprietary" extensions at
> this time, so not being able to put in those is a
> good thing: Any
> extensions used ought to be published and
> documented, in a revision of
> PEP 241.
what does xml provide...
generic language indepedent processing tools for
heirarchical information thats amenable to
internationalization and is easily extensible. all of
which are standard "xml benefits" items ( i feel like
i'm preaching to the choir:). the real question is
what do rfc822 headers provide, very little imo.
simple processing via standard module and low
developer overhead. xml parsing routines are also
standard in the library and the format is also text
editable albeit not quite as friendly as rfc822
headers but with a developer tool/module this is
mitigated.
modeling some of these concepts in straight rfc822
headers yeilds some fairly ugly results that can be
ambigious.
the cumulative benefits for implementations of catalog
servers and clients seem overwhelming to me.
>
> > probably the biggest problem with adoption of
> pep241
> > is the lack of dependency info. Dependency info
> should
> > be both version specific and capable of being os
> > dependent.
>
> Because package dependency is really hard, I believe
> it was
> deliberately left out from version 1.0 of the
> metadata. That means
> that any package author requiring prerequisite
> packages should put the
> prerequisite list into the Description, with the
> user of the catalog
> being responsible for fulfilling the prerequisites.
>
> So lack of dependency info is IMO a key to success,
> rather than a
> problem.
i think we might have different core goals. to me
depedency info is a must. leaving it out of the
standard and to convention violates your stated
principal above of using 'standard metadata'. without
depedency info i think there is undue burden on client
and server implentations for depedency resolution
(both for install, upgrade, and removal).
in addition, the catalog itself should be maintaible,
shifting the burden to a few maitainers of the catalog
from the masses of the python developers will make a
catalog implementation *much* harder to maintain and
populate. this info should properly be designated by
those who know the packages namely their maintainers
and authors.
as for depedency info being hard, i'd really like some
feedback for my metadata schema ands it
characterization of depedency info. sadly emailing
this will have to wait till tomorrow when i get back
from vacation and have a real net connection.
> > there is also an assumption within the pep241 and
> 243
> > i'd like to address. namely that the author of a
> > package will be the person to upload a package. at
> > least initially this is likely to be unlikely,
> > especially during an initial rush to fill up the
> > repository via some semi-automated extraction from
> the
> > vaults.
>
> That's a good point. Should we support a Packager
> field in addition to
> the Author field (which, of course, requires a new
> Metadata-Version)?
> Alternatively, would could encourage uploaders to
> put their name into
> the Author field, and put the "true" author into the
> Description. I
> doubt the true author would be happy to receive
> complaints about the
> packaging when she didn't even know somebody
> uploaded the package.
i would be much more in favor of Packager field rather
than introducing non obvious semantics into common
metadata concepts.
cheers
kapil thangavelu
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
From martin@loewis.home.cs.tu-berlin.de Fri Sep 7 07:41:48 2001
From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis)
Date: Fri, 7 Sep 2001 08:41:48 +0200
Subject: [Catalog-sig] metadata
In-Reply-To: <20010907052442.35461.qmail@web11603.mail.yahoo.com> (message
from Kapil Thangavelu on Thu, 6 Sep 2001 22:24:42 -0700 (PDT))
References: <20010907052442.35461.qmail@web11603.mail.yahoo.com>
Message-ID: <200109070641.f876fmf01404@mira.informatik.hu-berlin.de>
> second, please understand that it is not my desire to
> mandate any changes to existing peps or guidelines. i
> want to create a real world extensible system that can
> be used and tested before asking for pep revisions and
> or authoring new peps
So IOW, you want to create a competing infrastructure, hoping that it
will be better than the one specified in the PEP, and that it will
eventually replace the PEP. Is that correct?
Then, of course, you are free to make any choice of implementation,
protocol, etc., that you consider appropriate. I'm less interested in
such a thing, though, since I cannot interoperate with it unless its
protocol is documented.
> generic language indepedent processing tools for
> heirarchical information thats amenable to
> internationalization and is easily extensible. all of
> which are standard "xml benefits" items ( i feel like
> i'm preaching to the choir:). the real question is
> what do rfc822 headers provide, very little imo.
Almost all of the same. Language-independence, internationalization,
easily extensible. They only difference is that they are not
hierarchical.
> simple processing via standard module and low
> developer overhead.
I think processing of 822 headers is simpler than processing XML,
because 822 headers are not hierarchical.
> the cumulative benefits for implementations of catalog
> servers and clients seem overwhelming to me.
I don't share this optimism, but as I said: If you are planning your
own infrastructure, go with whatever you consider appropriate.
> i think we might have different core goals. to me
> depedency info is a must. leaving it out of the
> standard and to convention violates your stated
> principal above of using 'standard metadata'. without
> depedency info i think there is undue burden on client
> and server implentations for depedency resolution
> (both for install, upgrade, and removal).
Initially, and until dependency is in the metadata, the software would
not deal with dependency at all. It would be up to the user to deal
with dependency.
Regards,
Martin
From guido@python.org Fri Sep 7 13:27:51 2001
From: guido@python.org (Guido van Rossum)
Date: Fri, 07 Sep 2001 08:27:51 -0400
Subject: [Catalog-sig] metadata
In-Reply-To: Your message of "Thu, 06 Sep 2001 22:24:42 PDT."
<20010907052442.35461.qmail@web11603.mail.yahoo.com>
References: <20010907052442.35461.qmail@web11603.mail.yahoo.com>
Message-ID: <200109071227.IAA06818@cj20424-a.reston1.va.home.com>
I read lots of good things in Kapil's message. He doesn't seem to be
the kind of guy who needs a PEP before he starts coding. That's fine.
Sometimes you need to build a few prototypes before you can agree on a
standard; actually the most successful standards are usually obtained
that way. His alternative implementation can provide input for a
revision of the PEP. I would hope that (a) the PEP is written in such
a way to allow an implementation to collect more metadata than is
standardized by the PEP; (b) Kapil makes his implementation conformant
to the PEP by making his extensions optional (at least in some kind of
compatibility mode); (c) the PEP authors and Kapil can keep talking so
that Kapil won't have to learn on his own the wisdom collected in the
PEP, and the PEP can benefit from Kapil's experience. (Actually,
that's two PEPs: 241 and 243.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
From s-thapa-11@alumni.uchicago.edu Mon Sep 10 21:53:20 2001
From: s-thapa-11@alumni.uchicago.edu (Suchandra Thapa)
Date: Mon, 10 Sep 2001 15:53:20 -0500
Subject: [Catalog-sig] prototype
Message-ID: <20010910155319.D971@hepcat>
--QXO0/MSS4VvK6f+D
Content-Type: multipart/mixed; boundary="sfyO1m2EN8ZOtJL6"
Content-Disposition: inline
--sfyO1m2EN8ZOtJL6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I've attached a tarball with a prototype module installer. I did some
checks on it and it should work in simple cases. Currently, the packages
and servers file has dummy information that I've been using to test various
features. Currently, there are two major assumptions in the code:
1. Any package is available on any of the servers
2. Package filenames correspond to the directory they untar to (e.g.
spam-1.2.tar.gz creates a directory spam-1.2 after being untarred).
--=20
------------------------------------------------------------------
Suchandra S. Thapa=20
s-thapa-11@alumni.uchicago.edu
------------------------------------------------------------------
--sfyO1m2EN8ZOtJL6
Content-Type: application/x-gzip
Content-Disposition: attachment; filename="ciphon.tar.gz"
Content-Transfer-Encoding: base64
H4sIAOsfnTsAA+w8TXMbR3Y9AD+EEalvUZTWslsfXIAyCQGkLO7SojaOLO9q49Cx6ay8ohhm
iBmQI4Iz0PRAJG2qJlltypWkklQOW5VUbrnkkBxzyjVVueQXpCr/YM/JOe+97p7pwQcp2Zaz
SRmyoEF/vH79+n33Gze2vMZ2tb3PXuOnVq/VbtdqrAafhdu3cv/CZ27hnQVWW5i/dXthYb5+
C57r9dvz84zXXidS+tMRsRNxzkQYBp1Dxh3V/3/004zCHb6+3uzEnchbX+f+TjuMYh54Ivbc
ddEI256wVaPYF7Z+bjuNbWfTa/kinuGNMGj6m7btek0eeSJsPfPe99pe4HpBw/dERQ1edna8
6UW7dPXq1R97MXc4zuZhkzutlgYoeLzl4Pqey+OQb3jcD+CEWi343QwjboACMLZdaoYhX+J1
u6TGtbc3BTRIlKoP9OTfU+Ar03ZJDTG2UN30YjXiQ/iJg1zaAI2D4ThAbim/GwLmB03E4Yvn
iE2KIiDOFZDqtrcPK8PWS36TB2HMDWSr6QY1ZBpYir2dNkA9hJ7TOAxXBPC4Gs4wlkoXUyhW
txyxDt0V+KsGaOxXoWkNt8DLwv/cKy+2wmCzoje+Ak00afq5PRhqDvkUsGo9ArieiwtEHrBi
oMFLpkqpDwTYr/hBuxMrRvrAD1zuwN925AexIjiO4jg72nFiPwyIcxx9MMg3uImWFyhQ/MoS
n0O8gcOrIna9KKruRn7sVa4+CJ45Ld/lHdHBM53l7ZbnCI8Lz+NbXqt9FQ7BawkPZxuMAdsl
0Kv1NeiIo32iSsZTR0kJjPb2Gl47J2jV5TD+IOwELgFTuIadWOOqOJhOp4njiAWd2NkAjB8H
V4lfJHnxCfcLxAdsah/a/eCZ2C1yBcDgt17u1kyreoit+uM6JfhsacrlG/uxJwA0n+LIYjPE
xKuSUdamCWNC8u2lXE9ffD8NQY44DljkedDYNm3TppGdlMT9buh2Wl6lEe7sAAeJGTpQxVdK
cQiue1EbNdBYDuIxZEJC1WgkVtMQVsuKLGWUhhxL2yVcOj/gquaWVRCFAJhiDVGAabwTZDpR
KxvXOCtCxWm3o3DPBzw8QgsIYZfsHv3fUPa/8RptzBH2/9bC7TrZ/4X67YW5+Tm0/9j9nf3/
Fj43fj1ub/73371L519gp5h4DA8J/Gcxl7FtxloWe2QxKykw12LbBfaowJIhei6yR0V6GGKP
hlgywtwC+yVjj4ZZMsncIj2PsGSWuUP0PIqDVyrDsEDFgi8xDl85T2O5YbES/CkyMQcjAGQy
ypISzntuscRmscX8AnvB2HNY8DiLh5g/TD+LLBljB0Xmj7IDxl7AeMBinG1BFwA5wfb+gx0M
M/84DgY0oSX6N/YcgJ9kBwBknB2M4qyx8J9gq6dYfEI1PD/GktNs72fs4Jgx+zSL7rHn8HCG
HYww/zQ7KMjZ0zD7LK46FJ8hdM6qLvivACS5A8Oh4U4AFH36N+xhck4DGM0AnO8CMNoNYFQC
ICCPAMgEAlkBKkviivfh65vwsHw8JR85QwzhF6iR5co5fCrCF3heYgT+la6WOA2PPe6WOI4Q
MmeHfhsmTZyA33nni5aisbbsU36XORWRE6PwW+lIelYeA81HkyQbFSKlDA/PFWfhVx8TTFPR
zND+EAaCUA4OdaLrQo3ac0G4PZhp6mgo6Y66qTFoCybmGqcKngN9EWGqN7XqHrSbESauQk/R
KhZK1kn4c8YqWWdYyTqHz/TvLPytWyB0I2wUhe4KCt0kSy6y5BKLmRIlkL4nRRZeANb8HosL
zAe2HEI5eIFM+GtovowjgTsvoli+yfbPsuQtFo+gaElRfBjMs4QDU4MUldgTm4VXmAWf5AoB
tAkgDbaSq8wdZitBgVmfJdeZO0KiP2WMG5Xjvs/2PiOhHiOxBEH9PovukyooY/sB4gMyWjGm
lrAVBNC12cVmgU0QoGl2YOnGBVjs6b+ATN0wZh3HATQWMauM4RnMw9dXcD5Be8FkTrJyuGdJ
wifehK9D/Tp7uUU8cRK+8g6bLSUXJSznbdmpMIvz8NDPa7IrJ7WUg5csholtwZ2lFnC8SO6l
o0yd5ID1iMEgKTO5vlsfHIPf2s3Vq4CLl6GcSrcpXCQfNDpDNTcjJ9SHKJLBQjZuKiM848lU
vKwJ60Jh3BqxzoI4nbXGQNzOkoCNW1es81ajAIa1iOJ1HU3rLEuqLLmpxAtk605SQ2E6IEG7
A1K0UiHcP8gU6td0Q3MU/yh7/oZcS3u5UtTmPEciOk2NOZ0DMnaFRKB/16Hkz7nts4zYA8k/
blWO6SlZKqPXu0i5t5vpDCs2iGd799aDUQWpbMLqnaMR6JnbB9luJAdgNphkqD9+ZMlm5Mrz
hbEzYyjx5qfht7fC4PUmANH/Xxjs/8/funVb+f8L9bl3IBaoz9Xmat/5/9/G59qVmx0R3dzw
g5te8Iy392Ngh7k04xeDYds083/qUTGv/qkSgPoXcqBM3Ow4flBRIfUnnuPOemD0eCsM29IL
jaBNyFQJqRbXF20nBgCCo3FzOWg0HEiBdE/Ez6+uEPvyZ7XqHL8Xtvcjf3Mr5nO1Wp2vdBpb
ADJy+KdbTtuR6YvepMEKmNuW3wAr51XjvZistfptqlA5fXfLb3m8Tok8wnmJl8v9chFlQYjd
5eVpY6wa5gdV3HfLD7xKrpuoXRXtlh/LzNTq4mx9bVqmDY101dISr1G6Rc9cLaP2pLSI31SZ
p9oauglaxZpJGk1kSpOq3ISegyB0PssciAf5E1hDJY50j8IoO2wck0vQvQ8jW86+IJ+GqIvD
eMYHeOwajT6pOdhrncMsdH4qOqeGO0N4alfT/XN3j4P3Wq1w18vg98tiGXDMvJoBZ0plkTAF
OmCh+0HsRXKLq2qxNbnZMJLunFxYk7ZfQkwuQokgvU86e0ncpx3NFIgmzvf2oKUGtL9G4d2O
NCQQ0AETGTGdDvTAZj/zXQ9c0WYnaJCv0JAjcpYIoMVbvsgGxc42xoy7IQgntTgROgI6baay
ZnSMAMiLYsG9IMYxAApCz3jLQ0rs6EPgS3cz4EgiHKD70iX2CWActv0GTsA1Ym8vxs3CXhTG
sBe5a/4E1Li+u/ClKsHNwbPIby9d2kZQdGCwWcdcGJRZDCyKVES2gN8R2N12GLjYBKsDVsCh
z7wWQEj9MkJ3y/OjrvFyiUyR2NSwxL8o44mWF3n5Ppwjl/qiPMPLeKx9mknAF+U/z21z5deL
f0qvdCTiLrHRAg/oyc3gd7oF/EGY4gH3PwTdLGgM4EVoZUghe3hOYwuAyIO21YTqoSlcW93+
HDGIHKXDx0j71Zs2/X/zUZR67f7f4PxvvT5/az69/4UO8v/q393/fiufl7r/1Y5dCHIBlmdG
+4VkmEBk4HkFyJOz+z8BMWp5yjPsRKT7bgov7rR5hW5Ad0DYd8BSeO50f++u/CnZIc9B1FDL
dU3j+178OCgr5wNjJIhmczhgOpH3BLSiyh8oJwmhejvteF8mSs0s6Qz3m3YpdaW2HNSyct8q
AAdNirkan0ycxDBN8/BdP94iz9UuYYCdYVGV19ZpMnaJ972jzjtBd7XPqbeylG0muz7WXsO0
dgNVxxHXhVNkQtLR0g0xYaX+4FEwjJvtPnC6rknpcIx9yItJ8Ngq030dpJRMXNMp583B2aM3
ZwAfgDKgKlGDGTAZHaxXvRVULgtyduq5+AFaVmjPu7fE2uYdoJxGN3yZ5JgDkBOpW3G0vhs0
JpaX85JQ1mPSufTEs9v3jFfT6gTjyKuS/dUg8pt6hKaM27DtRssRAkItQ6qVvIctV+TFvfsm
FIsqmqBswDeJ19crwms1yeUmwvqx77Qwb5UDMYNuKwgoeS5A3A44mLiLwGt4QoC3I+GWrnEZ
+QXhrnRf3dATQTmGf/kOBIIzfAOkHZyLIO7AvvbloF0fQliaDOFYF+5Nv6XSXQDCgekBxEHg
zoYo7Dg92BTIp7CJ6vo6oPXMi1CaV9ey1rYTgezHsgPLQ0pGMQAuoEoFQlGFaGoLPPo2LIh7
hABSQizLS/vGBxh4wsg2KAU9EzytqGyUCjz46H4UhZHke4lBA3YWe/K40nn5OgAZ8AZUryLX
SaNTHRLl9pGLUnEUoLEk0YSDqaDWysZP8zt8TpWEKOCNVihk3AtNjg9htkSPcK+UdVo8hYEp
AMJvSpQ5iC0+T6dYKQpqpOCftrE8aO5pFbGWiPfTGSAiksJliVz+HKtOGzNslUFg66o0wWv1
QFXyMhvvt71yWoaTm4uUrpSj9g769SBngetEblmX5PTwzmoe5hopTWOHNC3V0aXSAHJKsUcQ
i6iuTapOyYnwyW9yRhJbnpVpCHqOMke+B4Hr7WFZSdax4+zpVmSQPLWn+Syv20o9QOjhxSvU
8Z7rwi+RUxSfYDepAjk51VztEK9glA5u+hG0yhFKQwzEUC67ediiqiQpgABUL0vkEzIvhQfc
B/xd3rV5STpiebmWPCNJP4K6lIcjVnvBrvXfy9tLHIvgbC3YCk873Z0ymp/C+XcRlIZT/AV9
qOJSXglB7fktV8f2ZPooIQe6Ewxr7O0o4mYEyPgnLQzLs69k8xTJI3g9x3RyTiYx6eF16TmE
OsNTbac2+p7YluYDFV5e1+P+7hEE0PS9ZkBzUI+Duhz2Ga2u6Da9wMNWMFwOcM4uEM6rkrva
D5LMH4GZaTnBthRMoD7G0WqKC9MVw8okJPpa2Njfy1EAFVs5kqcXZTbSYLb++UjtfMpxMgUn
dYvCom7nNM4A3SlnGxZvoBXbNazYgBzcPQetOf3QnhcCoNpTIHIH6Yw+d4hOfVytVnvq3fDY
1c79oEvOTKWmCPg4SMlEKpJn++nRfsor6nHkTc8od0e3QWj2+FikTfr7SDIx/6G/gZVhU+Jm
y9+4KdumRBV+C0B6NoWD1XRIw3bkNf29mVS9yw+ng8d9AzLrVKZZW3uJQSqyMIIQcnZUtk/6
MagUXT+qpPhq/xxHUb5VDV9UjKZ9H1/gNNzalMQ/hTBDU6d1TWvqtCo+k72ZVjTxS5+VHsxi
JakjzJpVIP69rriun6+McSEXIVfaKI46HkxudKIIEAHH0mntYrZbdkP46oCY8NRMGLXB3eia
Oq7eR+/V1B7UUkfsAFFu9rIYtisAR2Kt1F7X8lmY1seKOPBfFDn7OvwFNYUX7LoCaQDHd1kD
49CU7VJ6Pb1H0mvRyKBBRisXkgCu99K95dPZeotSKQ+EUOX8Q7AHkV3CICQPQoCWAauI/Iy3
8dpwCNBBLe8QpEqUY5Wz1JYdeGh6gGiDFD5oLs7vVzerEEVue/np6QoxxYuocYh6ClJuLGgl
mxLcN8wPv08aFgsCYEdRuBvwjf1Ua4FRJC12o/uTD/qkz5JCUmdCrRRGUX6krwkFh10IDcx0
gAzAaZzt+g2gqqpVQ0bSlWw60spV1VB6ZsPzQLvsbTkdzF1lK/5vp9h+oz9p/vc1FgAfkf9d
mJtbMOp/6f6//s539b/fygfrf+/q+t8RrP/9V9a//reY1f/2Kf4dNop/S0bx7+Ws+DcpY2Ff
k2FJH7S8YOznj46x5HMs6GtSAZ9uLbHkb7FWD+fZLPkHrMzzjrOmhaV4etAYS/6RuWPMG6OO
8bRjXJYZY93bIWXGFhVlicu422FVaRwz5lOBsUv1thZsaUWWNs3A16tktKnU6yXy17p0qquu
Dive0ro6uYm0sM0o+MESoerNVIRJ1WVJxWFZtYsVUrDfYfgD+/1P3G8Ji6WTE7hfrJ0uYBV0
XDCqPYdY+AdUB31QwAJIWad28YWswj6NpWrhW9B/hsXDzB/Bomu3oEdRnWTwBnSfM7qL+e4V
6J4g6Md0NfcFY7SqBJ1kezewhtSlivLoMtV2XjTGjWA5J0F8+s/sIfDRiqwE+xV8/UYm/2VR
5yTLijq7su+2eKOnM5dWt6los18y3M4qtWEecBayx4CybKSS3myfMs98tfRhzElDU5/QLFqj
Wm6circywzkW7oLfgwzWRndBOoTrsexO5cpLkrbFYrEwZk3AH9t6q/BW4SRWZbKSUYl5F8Xg
MtYqJ9ysxLyi5ADY+Q4WIhd1WWZyDbkSf0APVQETNeYy6r7CpYBZJDiksKcC3q68vvhYdX6j
mfxlWV6aVxb5ekyDpK9Yttl9OD2VjpflyliVPm7hHxqS817JFqF+Fj/FYyqjIXrEsJA7uYGH
gWYB9NCyNjmgv1a0yQEF8VibHFAqLuoOaZY+UUf2Fqrywy8rqCB+BPnk37Eg/gZL3saK3U3i
k3VYuoZvaOAzLD3H9qF3nsVUFe8PK+OBKu0Wi0dJfxXYiwLqzofBLEveYUOxrIF/U9bA30ZQ
vq2q5a1kATejCuB/wPa4BWyn3j0BoD9gEbNQZ/+QxePMP0GV68O0AKjJRRafwuJ3VOQj7Alj
4XWA+C5yrn8aQVjJHRafQZt7IOvff2ExfJEkWSJwZ3EyLEPKHoj5I9SwYJqfFCSk3yJcAdh5
Y3iJhpNi34Ax79Ecm+Z8DL9/Ww8C6w0Gu1lgT0ZYOAk99/RqCJQK8O+Q5bhPKI7reYCpLtan
d17+kj1MHphb+ikJJ5zHBEt+hyhASCIRSmwSOy4QTckpED8kof2KF04kGyoIoRLbaFnqXXxe
kuX9b7CsvL/fPYbUpARDGoSxTNlR4pO0YNTeIXHT+U5xLQd2YD6/MqnNAAbU4gI8rOfkK017
iUt9+rJkrMDNhFLMMUdDgpvdURFyOotHgzCvR3uTGTIilbqUIpp0L2VmbZUhURdPSi0GnjI6
aHnJftC1EyFi4GkaMMrKkRoywko5FW9xaJn0xoagyzyS+N5AOlGGnQxLd7/O7EvNkpLcIEG6
j/y6OdLld3OIMsVZOjV4Qxof0KNDY9ZYYcQ6D+butHXKGqNXD/DXuHXBmiicsq5D6yVrsnBt
aBx6M993ArXrMks+YsnHqLWkcsucXoT/6vctJA3L0lqkFDmCuNLF1aMPocAZYpLuG6Ll1NMt
NCxt4uk9xhWWfMqS31f6QGoZ9G5PgdL4GapsUB9aAT6k/iE19iK6up/hjyGfXICFAmr+R6h2
VjIaXUrdn37XQyTdy13c8XUYjQhi5E4Ole5My3SdhtExmNSnmHzLzST0ilRV8p2XU/iWSyFj
J1SrYHyTNZasayuhQ6nwDBD4D1UrhgErwTFo2SBuy155uUsc93UupHpVqalCVbSVEuII/We8
/ffSHJp/oRGv2x5Lrwm5cwIJVtCxWBmdC5clHks2e2LPZMtokq/aJT4aMbTKT9jeNn6DnR0L
16Fn2xisvIgWNaUvyILDsEPuCMEChwGt8ziMC/AHAA3OwY82HVGJvBG56NN3mfUwecr2wbRG
LKZX4cCzQHdjCPyZ6ywR6MUkMS13gjBQL+h10HFYAdn6LHlGkRyBhi3Az+gSobRLb98W6MU8
ZeGf/hdY9z1qP0nWHYFUUEeKRfj66td4pM9e+crOJnkdfD+noq6JdFD3nZu08Pi1Sxi88k2W
vUxMbRv3URUUzsPjMmRVvK5Tps/1pYufWthMB6Tm86VcBsNipiY/Z80M49f1lqC8MBvOSWDP
VLVOin4G7gihy7sTLiNDikJ3FvRUyRphx1FfoVksTFoj8C++r3fcOgnGctKSKnqUwLhhA7Zr
2toBZqeviuyjAI70fbKdDQ6ictPLUg+XYHdj18eGx0pjx/oH+lkoRRHv5zqU+oIlB0Yo9aUR
Sv2VEUr9KgulPlHvlt9gOnx6mRtNSjxRJPX3uP4BS57jslJZxUwpt4vqqcguNotsAhXDH2G0
hSb4j1W6R6ojjKp+wfZ+rKIqeI4WSSO+oGGkuDAUKKBqVDFDiIrtl0wGUdCchhEfg6L5E3r3
F45nHEkj97hM7+cedclKcu+nuTm6uJTxhSmX8gaWTsu8S5XuoL7h7MqHKLdbB+EuOFf4rC5O
aTW69Mwcc8qs4AVqt3iSjGGOc72HNYyLti6ZzGOTxzRb3EDpJV3WA0YSU7TKxRJIImZkOMge
ZWXIg7iJPPIlS/6UJX+mzsWXweJxOMI/p7wu+Q1/0eU3/BwF5HVd3mb/FwTlPnS/nf+SRM77
YAaQQ8iXO4ovlSNRKKLmKhDdLKQbij7IbfLX7H/au7bmNo7sPCApkoBA0bpRpmWvR/IFZAyC
AEiQFiXbWVm0bEdWZFKSN6aYFEiMSKxBAMJFIhVpkZTLqWyqdre8KSflXCp526Q2W/kXeUnl
Oc95yHP+Qs6lu6e7MUOQkkjbpWkWSWCmu+f06dOXOX3Odzp/TUzy96fXdM48g0NhwQei+Eka
hLnEE34ldu19/byJpKYgugRMO52/cTp/K7aLy6TOp4e97aj94b6Pmu1Xkt4dttctn6EC/cbX
uvOwCl1UzGGmMcassNfiEDjvP2QtGywQseTR5HByUCwEksPfOp1/cjr/LE4ANA4nYjqHn/cD
9uv+AZJ5vt6jT7ADld3Ct0IiBvtjtl7CX55pCP9GLs//4nT+FVdcejouRr3O1zmnJmq9KLQI
+Q3TiPJiv2JaNP5W0vhvTud3isb3SQif+tD+iZqh0fpbvxm8FPeEBBBrrbmVJm2TpR/XVeLB
7vuGhIScuxiCQd98mwxbZ2W1jWFHBL3dz9Pp28uz7afp2Ai6gmEvUAWhXNul5yQ6AW6tT/b9
qC85kDyVTIwtj72aPDaOnRilw0jv316ePuhnZLOzu+E/YGL7j3xufiZfQHuRuVzBcQsHTRim
59z+A/t/qVZrHeQzeuD/ZbN59P/MQ//PZXNzhP87W5iL7H8OIxH6R6W2XqxMr99vNkASInu5
5ynR+PfqtWa5VWsckBN4z/GfnbfGf34+F9n/HUpi/KdozD+vCcf/ImvxDuwZvcb/XHbe2v/l
c4UI/+FQ0vS1j95fvL68OJ3L0M/0Z17J/cBbc/Nvu/nswkx+YSZHeFrT04lpBRYHufPTy+2q
u+zVXfeCm59ZyM4uFAp+TgFCBxln7IxvL+Rn/IzyhTAo5/zCbF7llMgvIusnNc6ay7q5CwuF
CwuzfqU6ZnpA9rmFArRs3s7epFbpGYHS7EL+gsoo1BgB+XKFhYJf4dLij698spi5snh78dof
3lhcsgtArbn8QkERfOW7m399rh7cM3qM//nCjD/+C3M0/vP5aPwfStob/strwrpCgox1AcK0
G5VKeS3t3m3V4T/kp1cKOzsPduW0huMzYflONnT0GHVyw4pO3xIkxFNS1az8fiUMAp+zq7Ag
mk+ZjtagIFn0CcSKCxLkZrhbsBGrdr9ypNG/LQ4HfQ9wZa8OtN7mm3aECJFTA5KwnvWWm5pK
wV/rGXA5A0Kf2XiYMv0ifZc+RHKwG6ohzZjPIfA3DXTCL6H7Kmr5J0OcltncXRS6U2WvW6Ok
5g9pomkAl5a8ZrvS8rkAlyYsv2J2vhfdc9VrCZCEK7UH1UqNdeviSSkKFyFrFzW2q3g3uFLR
+aLGW5SzV31kzGRXx1jSDPC3TofF7JRt0H4ZS4pn0WfzUQZryAmuq3d2ZY3ZGPEt4BHSuVqO
RWS57hZ6k89iSoK/RgQWhQMEM0UrVPTlXVuE0Ku4VX9fQgq655cWby6550G27WqV+MtxkmDs
FeHOI7zRrTzCKZ0c75l2GuhZja26G77MIv3hTTAHf9IxISYYVwOasSwL8PSZ+eDmDXFTPkzL
loHqqt56S3OwVwgwzdr6F14r4ykYGClO5/mOS3coFIhRZaW2Ua5OpIrVWnVnq9ZuIjBJC5aA
379bq8HztlLh1IAINNbKCDw44XcIoy8wh3lwcwUmN3M66Tp4TdhAtRimeeCLSgSntfOLXYa9
wBSwhdOlJbFY3RGnVufOSwgZszsDgEomu92l1aShDwueHbSTsGaNz8zK0IRiFWMy4NTQ0u0c
2aNVPeA2rK7kcM8L80QKdzHb9x/eVWgFhjwLSDCtrISQVfgIvr95yEQj+NWu4qME5cgc2VCe
zfR2XmZjTdXMNp6vIsZvq90qV5qiQXXkZLV1pdzgFsE4WX/A0yJ8W99EXIAUmdekCBdAZU/b
rVxZmJpnZB4Dk8QffzoICuFaEAqPxocutgpAZJf8/GCX7K4h+X+CxQxotD0XR5akpEQFd4lq
td/UyeCuCs25exeyEa3WhT6QStdOQEM9C+hI1Y/PqhurWjc+s06E++7UrfubMDYymDdwX7Hv
rhSsSklCD74njWVZ9KU0gzZ70wffDsBk9EEouGjDu9eGyZ77UczxctZpaACFDRNhUF7NaDsK
OZlrhKbd7UB45hTbNJS7NhfoznKnerV8H68BqxHLBbtse/JioldUtO6nXK+5zfb6pmq0t43O
ducQVuciYk49CfSfZNwesP90ZD8pMKsCT1ui9unXz8u6lcff+WeN42BIkQ3ksNyuew3OR8Ya
QInnP63hVdg+2sdg5k0W7SuaXSgPQXKrfzHQIzRJMGP1BdSozWkB9blc4ZrcGPesTu0JQokr
aa8I8JVQAB/g0KytSbDloKd816/3PZOv/zk4AIge+A8Fif87n88V5uZmUP8zUyhE+p/DSIj/
8O9n/5HxH4YQ/+F/nWD8h4Hd8B/wwxECfxikz4MI/oAfhgj5YRjtde86wrJcIj/sSOvyuNP5
SjrqJhy07h2UeA9DOt7D1+hQIvAe4hreA9qpJ+QNHyHiGMFIBCBEjPZGiCBrKTWl+jZwt5E7
w9IGLo4x6Xwz+hOaGX1WM6O/pnkk3/I9kjsbAgoDeLW0zOFjXEcCTYQrv3yD6Q5Sk6BIeOzw
yl7JFAxPxcbDK4MYDA/zDMkrwwgAIWzfExQGzyFUBXLw+ZKvA8tfEL7J0Mgz+CnpnIE2ntEs
5tFw7DqZc02REZpQLbH9nebobpqfKTNctP9SZrgNuc/rin6D3zVNHFmx6sUUfkCw7dtpK7tv
dxsUtCqoYhGMTqjiurIJ3VoXXfLVxDI+tp6q2cmhlV9GO+wwbIYT0v/uBP0k0XpeOTyiKIMI
dk76znf4gRweaiedmLg6oF19g6IN+ngaMXGP46KNUQdXGYkDY7qN021G7EBndgoTh85fZ51W
QnipsTflTzqvODvHEV8BS5Dveozyv0r5XaeVxPGh5T9P+V+j/CMif8rpvE753yAaj+Hlqx92
3nRao8LNTZaecHZgmplkmt6iMmn0Ay8d0XNlqEEktYMktSI2mmb/Th0boA8kuerS6pE/g61/
I5Hu1plNHDckIFwiu0MVBsmjbi++qyPYqFUBCLEci6wxpRzWRqhrWLIWg6RP3yMRW/R8tOci
mZXaS8rStW2jdgVtD81xYhC62ygZ8pl2gp2U+mPTfS/Fjvahmxf8wv/j2v9j9GkI76L3wRB7
ZD7EIZR1OjmEdegeRRhKdIZGySDPhkecM+isxDgP9F1BPXTmyFkTZvx5Z+d/ELZh+7/x76MB
J1n7TxhSF8TMyqNDYDeMCClHl6aLzs4pp3OJooBKTAcYFOeczjvOQOu4Uz5BIBKjDCLxLo6I
qx8yasR7InQoiD/7aiJww85rDkMzlE+RgxSBONC9y7jOkjvneafzPlQ+RjWf5JqvOK0z0k+a
al+kSl6kQXrvDtD0WXXC6XwA5cad8ktUdIyLXsWisGaLMUilP5LtPquwG/phUMalkyc6H4bo
jUmqSdHL/pTseomLt67eTJDUKF0myYquzGSfrZQjXTF7KgCvT7xsCGXo2nOUpVWqnkPH7qg/
+6u8YQsHLTy+ZtV3uqTrSstKX33tatiyGuixqLldDvLDKuU1mlQ+uHmDmKlUrjztsAKayxHj
2S1MIS2QOpko8rXD2oykw0IEzT0+jIO2fbDt0oNdMnkTpXoqgEcaK82WWQzUmBLQXbtNRUdo
wQYuZxVEA6zTp2Kn++Iw8aAf6onYKHw6BT8jNDkhVMNx+BnDa30vaGv6J7jBu+Z0PkGUhpb0
nvcXaZxobghYInToRj+5Txk+BiEOlnHdVCsl+cuRT9KcWsz2q4SmftB0zewPRtIbpB5mv1rh
tDDIyxR66YeOJSX2vg/U7WIleA0JWCtUid47Kl7RrvlwROOxF9CrDp2kaDH4D+T9LadzG3Eg
1P4a5/s/oq/0+vOoz5/4j7oqpOyK3E7TfhsYj50Dk2LnDhUdFp0C3VeFWbbzx/LqEXEVsRIY
wQfKnYUcRfFI4ZWPyAlD0MkufCxZtzzajMlJl0DRKErxq3KvEq6R9z1ZyzSQJAwN4iSEa8LJ
+T1Y090lHqbqmSHKNPFgpTEjoihFKE8IqB3dg9yETHwBXtmaOO5F2EzkCLOESW+vfYrYJd1i
1AAUvdHYeRC/sb4TMPhRCGkKEGL4XyiGG05n0+mUTTH8aU8xrASJ4StwY8sXQ0ZlGNOksdYl
jfcsaWxYItf0pbFt3bqPmBEB0ug6PnJa2MFCmDiO8n9dp0+oKWEqeiGFY0oKbaW54Vv11HJY
fWI5DNswmNIWtnV+NhIad/h9ky5sKBmNsYy+oskoL7ah/q3aljzwJSTkFSP4jcLmjDxzUA3Z
pTWq2DBHwyav2OHkj5IvJ+PJE/5I+yWOtB1ESej8qbPzOsIVKGhACX75mPbN/eIF9XOn8zPY
9g7QnhekH3HZYp0Ohj4HiS2T2kvimlSn4NafEfYb7H6xwEu8Sf5zLbtAJ8CNMgxNsVoTYt3u
Rze8p8XXnt1OVRL6oUqChkzI8YhEjzTYFwLg2DB6uusNESnb3nPg8K4g4CzVYU+mynfrfxwO
eNayI7EH+gn34zj8noXdlhWb+yun8xdO5y91RMifB8bmnnFM3Mc9nggZnDruf/ZPezSEIiz6
NBG0u3jR5cr5lYqh3TcS6+o5y/H3F1Lp+UvEGpCOv+/An6c6M+rp8tvVDJvOX2i+yyFTo9WU
r2VTfo2ACbIpLwWNHrU07Z/OEFq+1sgN3GlYxH4jiSVIBEnsOPwJPebaP62BhHyjURrwnmbR
+a2k8++czt8rOvOKqfs5Qdt/AwLo+1ZzBie8pCdxBmfDVv292Hon1ectc7ZUY7jbhdp0/O6a
MkMkJ0STFtD0LuW7oiWsapN0wYjg5wWwZy9O4l2ttLmn8TioSbt0vuFL3p/qO903di+ZTA6P
D+CPE6XwZLpKHMwzetj/z2VnZhX+f2EG7f9n8FJ0/nsI6ent/xuejAdLvgC72/4nLMMLEadz
lyhJxfvFcqW45u99gZw4IetzRfCh3eQI5/BSEVCBMuvHfW4iXmy6JQ/xsbzqetlrZvYRmJKe
d7/YKCM5SEZ8ySsC0f6m3H8265AZXVCEWVeEiFDbVTImxshJCKdabCDUVIthBVuN4nrLp3NH
rzrjuhxYAKoms7vaGtCzI0FzKgiqI0FweGkNJRCKF91qrTrFPdZQfsBuEW2JtzxGec2wgR/Z
TXsVigC+ksKXXDQTFgef+LEilKMU1hA4hv+LbXglb3Bcc2hVSo+O+cWGiAFLoTERlfAGceEd
oAQV9XUEtmmkJjK/995keve/7p0V+DB5Z5WDpRHjdqnM1f/Z9vI9AnPKbmQjTmjEfkNzCnt8
Pe6mqCUg8KZ0GiEWxaHv4F3tHVfxKtP0io31zQkzKKYM1UnZMxuNWrsurM2ZM00zhOTcakDJ
+kSluLVWKrrbC2Z0ze3JtFaYar1Le2YMQ4gxRItV2MAVRLgu0YIVlpwVyrVqhbAsy7iGGnlG
lFFxGZh6UZnOxl+jPHUXx3jzXrvY8Nw1GDZ4GqFU2bogNLwNIBA12w9qjS/MpwU2F4ZDpbju
TWzDc1dRglPQclFmcp/lV7rK+xXwRKT6+DUxFxg3KcIxs1IynO8jx0WdzHApIlrTpZDwJTai
L99l6XDPveNel2EESQhawZID48PbqiOVPPQXKCsGjnNTW+Xq7WJDXsrRpeL2bU9dyq8+Fvb/
WqNWZA0oDli5JvErKT0nWUbqFzR3FjGLrBghUVd9Nys/Aqb0ogr2FDNDYYqTdVe6TBnAVXbQ
T0GCCnhpVy0510WxyrbqGwUTJ1bUtGpGwCRjYKUZmfTbZrjJ9GqcnKcJK+8wG6UWiD226goL
ds9GdQ2VQ22VKal7a9kyLI89m4Vr6KH3ES3cu7cinjBjyrJr5G7B+bSMT4QcqJXPxJ8BbKBO
z75BA7XCITH5VFA+g0HPPCCf6hLbiNtC4vOPV0QwIYa7LvNsIO+Viq3iWrGpWS9/1+8mUTr4
ZL7/H4wNeA/779xcXnv/L6D990weskfv/4eQ0P579f/+ge2/B9D++yvnWdl/YyBA2+x7CENo
CGvoYbKAPuJ4cbLP9qMCJtg+G/W/ofbZlkGwFTMqLpXRI2ja7FtoL2gW2pc1C+2PNQvtpe6Y
UdtOOOj5QSso1mPQK8N4RDXX52BrOqcxWF6JbH6gBaUBYea3MUhWhC9qsanGRVQqjsiANgMv
ySvD0qDxZYpf9QqaMJaHKUBDnG4dQ+tdjPdwDI3rZbwHMuEdaI3QAWaCDzBdYdl3ztn+OoZx
G8iEsXTUgSuNn8Uew4fzSNTjITLw7cOwTY+OStuC1+lE9SQZNYBEvOE8Gkaj/fHH0HVvOq0x
YbgPV5GGYYwHtp0hu8JjFMniKF5pnHUeJzBCGGR7lHDGHw2hwSR+unTvVOyzzqTDtomPRpzS
KFUEtaep9heo9hF5cYouHjcvThP5STQM3f45VXIUPzceOY/jZCo6SG2KyzbNYJtarzg/7Xdq
N2HszGpt7McIYFDdAAbJOuqM9+HJIn05gV9Oii+n8Mtp59LjUTQlfTTqPEo6osQlQq//K2jW
PF0dckpjziW0LR0SkOnIQsx473fOZ6UzMJQoJNSRmBn36rnVZ9FxCFlp4BQjTffxPFW+obAZ
BXCJAfVJicVGjtiW5hTOTPtRS9G5S4DuyYx9SOHEOK4And2o0Dp4fIWDQUYx+hKnR44tRKcx
dpAsinTFZ+Mq+oh+TI71ZSyYJCLlEmsx3n3TITiw8hFZ+iIRM6DCRqV9Yngm+rLf8AVZpfJd
1CG/hV7kqehLM30WUVM9iFo5WKKmBNNisn7Wi3BMOPpOShE6v9Kn+OsTrszBajLLS0Bb5tRL
HB3RNYQbAGs36QxPaQZpgdSUQE8WzI1A/Vk5aZjthgRr0yMjsAEtKp5IJkmjxLZVpFWyY7gN
KXL5AHarWKdypE4U9h8YACswHpzNUcolakPirstAOKRyokv4tsvHworZPpkmJ/2COju07rJZ
rbPBaqZGmN8mxb+uduhc6eohasIe5FMebIw6zcsOAdH3ncUwcbETKmzcMAWNi5Nl8ghcw2/j
sdP9p9FquQ8jdZyIvQD3snB1BK1m+nli+gMcdgvoq4COCsphgmN+vUpRJUXoNYyoBvuPdylc
JQUAGyGvhNYR4Vvgx6zA5uxVF6fP4HagtfDBowX26nIAk5wNsEIKc9/ac2+YTmQLyvaYoqmN
9ll8vYzOGJ0rgXxdtPj6gcnXD4P46pp8DVQDGqvg95+hlsfF5R4c/RjDg3auBXL0E4uj102O
3gji6Dmfo+E6yID5/vvOViGnQv/6cQ+uLok4i0FcvWVx9bbJ1Z8EcfVFn6tdKlC1Mfv+M3GI
mYiq3iWbgz3ijVnOprZfkdk9+oNsO6nQQaNxKi6CiQ309yXfSg7jjxUt5nP0R+isdUeLiYVG
i3mONL4iSIzF1T31hGkNjsU+V8Fi+gyZtIztNqR+g7wCdGPMp9L99rS7C91jSDo3NKM7siDe
q9Gd2M9q2zvdzkwzuNOYFcA/y7TOGNbkd6DVFlBaC68SGuJEr7OLItEMQXsvzknDNWQSGq4l
+8c+TeLDDy3JafUgn9EL/7mQzQv8j2w+V0D7r9xcIR/pfw8jPdi+QU4zaTefyWcKaXe63l6b
vlurpV03N1O48Pbs27Npd6m2BjPGlXYV8qXdldVEtb1V30m7uXkolPUL5aehnnxutlDIYUbK
SnXlMlmVD31x4Uo2K7KsrBUbnGOW/+Wyqxfh4sO0S5dWVxN6DlUHPsuvpFlveOubHhFIJah4
wcw/o/KvJvwC+cyMQdqsluvGztWGt/zpNSibyYtcOvGrP/BTMhuq+iCe0WP85ws5Lf5PlvCf
Z+Zy0fg/jAQLmXhfKXn3vQqsdY3mQiKBOlncCdXdCl4Wxpyw9UEAeDKgauJRNdt2oum+sPZU
umBSEsONRNHfrQm9sWEozoplr7i+KarIWPdbsAGDvcyDWgL2NVhNkVTM0vGFHoiOL/RB7AeL
pZKLu32xBWo2a+tlGRWa/XMSFDVSow23j+SKKKtDlpD2gUvAfnDZU34+6FtI73hVN+FtF7fq
QHcCuSYD3WE1Sj++GXJytFUmXZqZOQG7h7oHRAHbdzJ+jbBnaeIGg9+G4GqZg12SCSG1hpiI
XxMYSVq4VGATKF6rq1BpV/gT6r9X4QEWmVrdCdJJWZW7WuWG/p1eecXOW9RJqn0vwZmQWNq9
66XgK3Atoaioku2k0Oek3VIZ5mhU4KfpTTDtsiY+jTtZb7pdpYM1UsIpy7pE4sEmbOTlV3wC
PRiDfDe2YKEQT0q7qJ31oC7Wyq6m3UwmAwzhywnsFL4jveHhla+1w97wd43dM8YxrNZMDQCd
h0gahFhCHejv1oLRASVW4Fk4+haQbVCV527BXISZhJ8mfGw98KAaJYb0cFFpxhWjtMktK4Jo
oA0kqm1JmjdRcYodAjV/lNqizT+8IFXwJaxWA6LrdQ6eivVvuY3yxmYLMj2ATkskbtZKNZgG
ptzLXgvPX8hXC8pUSzSo/RvwltDeAmJFd/JrRbPWbqwjzSUPs35UXa81YKLAIUhuP9DCWqu2
Xqs03Yk6bLfLeN4Db9abMvY5sOQhNMTFd5KSkNz3JrGuH1cqtQcoBjWUoHW3XS+xdxl0Mo8n
fTgZsqZRjZRNq5cfr1neQNrXK23pR8VEodFoiW4KEQK6NxrFrRRJLaq2yy2QT3iz+cHuAsT0
cqDP6B3/bVbu/3Ps/5HDMBDR+n8ISa0KdGS6WYMZ6Acry1GKUpSiFKUoRSlKUYpSlKIUpShF
KUpRilKUohSlKEUpSlGKUpSiFKUoRSlKUYpSlKIUpSg9L+n/AUJ5770A8AAA
--sfyO1m2EN8ZOtJL6--
--QXO0/MSS4VvK6f+D
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjudKD8ACgkQ6nShCjt5AZIzfgCfXbgMwKcTIv0pMVqAEh9LUoYz
RUgAniESd8YKVA5fGX/Xp/wlgnEVGcwv
=hKAc
-----END PGP SIGNATURE-----
--QXO0/MSS4VvK6f+D--
From k_vertigo@yahoo.com Tue Sep 11 20:04:41 2001
From: k_vertigo@yahoo.com (Kapil Thangavelu)
Date: Tue, 11 Sep 2001 12:04:41 -0700 (PDT)
Subject: [Catalog-sig] metadata schema
Message-ID: <20010911190441.53237.qmail@web11604.mail.yahoo.com>
--0-375289087-1000235081=:52800
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
attached is a xml schema for metadata. based loosely
off osd, xsa and debian's control files. i stayed away
from using namespaces for simplicity.
i've run it through the alphaworks schema quality
checker, so it should be syntatically correct.
overall, the format seems a bit verbose. i'm bit
unclear about how best to trim the format, or if
client requested info will result in a trimmed data
set.
i hope all subscribed are well,
kapil
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
--0-375289087-1000235081=:52800
Content-Type: application/octet-stream; name="package-spec.xsd"
Content-Transfer-Encoding: base64
Content-Description: package-spec.xsd
Content-Disposition: attachment; filename="package-spec.xsd"
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KPHhzZDpz
Y2hlbWEgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNj
aGVtYSI+Cgo8IS0tIGRlZmluaXRpb24gb2Ygc2ltcGxlIHR5cGVzIC0tPgoK
PHhzZDpzaW1wbGVUeXBlIG5hbWU9InBhY2thZ2VOYW1lVHlwZSI+CiAgICA8
eHNkOnJlc3RyaWN0aW9uIGJhc2U9InhzZDpzdHJpbmciIC8+CjwveHNkOnNp
bXBsZVR5cGU+Cgo8eHNkOnNpbXBsZVR5cGUgbmFtZT0icGFja2FnZUhvbWVV
UkxUeXBlIj4KICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOnN0cmlu
ZyIgLz4KPC94c2Q6c2ltcGxlVHlwZT4KCjx4c2Q6c2ltcGxlVHlwZSBuYW1l
PSJzdW1tYXJ5VHlwZSI+CiAgICA8eHNkOnJlc3RyaWN0aW9uIGJhc2U9Inhz
ZDpzdHJpbmciIC8+CjwveHNkOnNpbXBsZVR5cGU+Cgo8eHNkOnNpbXBsZVR5
cGUgbmFtZT0iZGVzY3JpcHRpb25UeXBlIj4KICAgIDx4c2Q6cmVzdHJpY3Rp
b24gYmFzZT0ieHNkOnN0cmluZyIgLz4KPC94c2Q6c2ltcGxlVHlwZT4KCjx4
c2Q6c2ltcGxlVHlwZSBuYW1lPSJjYXRlZ29yeVR5cGUiPgogICAgPHhzZDpy
ZXN0cmljdGlvbiBiYXNlPSJ4c2Q6c3RyaW5nIiAvPiAgCjwveHNkOnNpbXBs
ZVR5cGU+Cgo8eHNkOnNpbXBsZVR5cGUgbmFtZT0icGFja2FnZVZlcnNpb25U
eXBlIj4KICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOnN0cmluZyIg
Lz4KPC94c2Q6c2ltcGxlVHlwZT4KCjx4c2Q6c2ltcGxlVHlwZSBuYW1lPSJy
ZWxlYXNlRGF0ZVR5cGUiPgogICAgPHhzZDpyZXN0cmljdGlvbiBiYXNlPSJ4
c2Q6ZGF0ZSIgLz4KPC94c2Q6c2ltcGxlVHlwZT4KCjx4c2Q6c2ltcGxlVHlw
ZSBuYW1lPSJwbGF0Zm9ybU5hbWVUeXBlIj4KICAgIDx4c2Q6cmVzdHJpY3Rp
b24gYmFzZT0ieHNkOnN0cmluZyIgLz4KPC94c2Q6c2ltcGxlVHlwZT4KCjx4
c2Q6c2ltcGxlVHlwZSBuYW1lPSJwbGF0Zm9ybUFyY2hUeXBlIj4KICAgIDx4
c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOnN0cmluZyIgLz4KPC94c2Q6c2lt
cGxlVHlwZT4KCgo8eHNkOnNpbXBsZVR5cGUgbmFtZT0iZGVwZW5kZW5jeUtp
bmRzIj4KICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOk5NVE9LRU4i
PgogICAgICAgIDx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9IlJFUVVJUkVTIiAv
PgoJPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0iU1VHR0VTVFMiIC8+Cgk8eHNk
OmVudW1lcmF0aW9uIHZhbHVlPSJSRUNPTU1FTkRTIiAvPgoJPHhzZDplbnVt
ZXJhdGlvbiB2YWx1ZT0iQ09ORkxJQ1RTIiAvPgoJPHhzZDplbnVtZXJhdGlv
biB2YWx1ZT0iUkVQTEFDRVMiIC8+Cgk8eHNkOmVudW1lcmF0aW9uIHZhbHVl
PSJFWFRFUk5BTCIgLz4KICAgIDwveHNkOnJlc3RyaWN0aW9uPgo8L3hzZDpz
aW1wbGVUeXBlPgoKPHhzZDpzaW1wbGVUeXBlIG5hbWU9ImxpY2Vuc2VLaW5k
cyI+CiAgICA8eHNkOnJlc3RyaWN0aW9uIGJhc2U9InhzZDpOTVRPS0VOIj4K
ICAgICAgICA8eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJHUEwiIC8+Cgk8eHNk
OmVudW1lcmF0aW9uIHZhbHVlPSJMUEdMIiAvPgoJPHhzZDplbnVtZXJhdGlv
biB2YWx1ZT0iQlNEIiAvPgoJPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0iREZT
RyIgLz4KCTx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9Ik1JVCIgLz4KCTx4c2Q6
ZW51bWVyYXRpb24gdmFsdWU9IkFydGlzdGljIiAvPgoJPHhzZDplbnVtZXJh
dGlvbiB2YWx1ZT0iTW96aWxsYVBMIiAvPgoJPHhzZDplbnVtZXJhdGlvbiB2
YWx1ZT0icHVibGljZG9tYWluIi8+Cgk8eHNkOmVudW1lcmF0aW9uIHZhbHVl
PSJQeXRob24iIC8+Cgk8eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJRVFBMIiAv
PgoJPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0iWm9wZVBMIiAvPgoJPHhzZDpl
bnVtZXJhdGlvbiB2YWx1ZT0idW5rbm93biIgLz4KCTx4c2Q6ZW51bWVyYXRp
b24gdmFsdWU9Im5vY29tbWVyaWNhbCIgLz4KCTx4c2Q6ZW51bWVyYXRpb24g
dmFsdWU9Im5vc2VsbCIgLz4KCTx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9Im5v
c291cmNlIiAvPgoJPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0ic2hhcmV3YXJl
IiAvPgoJPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0ib3RoZXIiIC8+CiAgICAg
PC94c2Q6cmVzdHJpY3Rpb24+CjwveHNkOnNpbXBsZVR5cGU+CgoKPHhzZDph
dHRyaWJ1dGVHcm91cCBuYW1lPSJwYWNrYWdlUmVmR3JvdXAiPgogICAgPHhz
ZDphdHRyaWJ1dGUgbmFtZT0ia2V5IiB0eXBlPSJ4c2Q6c3RyaW5nIiB1c2U9
InJlcXVpcmVkIi8+CiAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJ2ZXJzaW9u
IiB0eXBlPSJ4c2Q6c3RyaW5nIiAgdXNlPSJyZXF1aXJlZCIvPgo8L3hzZDph
dHRyaWJ1dGVHcm91cD4KCjwhLS0gZGVmaW5pdGlvbiBvZiBjb21wbGV4IHR5
cGVzLS0+Cgo8eHNkOmNvbXBsZXhUeXBlIG5hbWU9ImF1dGhvclR5cGUiPgog
ICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJuYW1lIiB0eXBlPSJ4c2Q6c3RyaW5n
IiB1c2U9InJlcXVpcmVkIi8+CiAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9InVy
bCIgdHlwZT0ieHNkOnN0cmluZyIgdXNlPSJyZXF1aXJlZCIgLz4KPC94c2Q6
Y29tcGxleFR5cGU+Cgo8eHNkOmNvbXBsZXhUeXBlIG5hbWU9InZlbmRvclR5
cGUiPgogICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJuYW1lIiB0eXBlPSJ4c2Q6
c3RyaW5nIiB1c2U9InJlcXVpcmVkIi8+CiAgIDx4c2Q6YXR0cmlidXRlIG5h
bWU9InVybCIgdHlwZT0ieHNkOnN0cmluZyIgdXNlPSJyZXF1aXJlZCIgLz4K
PC94c2Q6Y29tcGxleFR5cGU+Cgo8eHNkOmNvbXBsZXhUeXBlIG5hbWU9ImNh
dGVnb3JpZXNUeXBlIj4KICAgIDx4c2Q6c2VxdWVuY2U+CiAgICAgIDx4c2Q6
ZWxlbWVudCBuYW1lPSJjYXRlZ29yeSIgdHlwZT0iY2F0ZWdvcnlUeXBlIgog
ICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIiAv
PgogICAgPC94c2Q6c2VxdWVuY2U+CjwveHNkOmNvbXBsZXhUeXBlPgoKPHhz
ZDpjb21wbGV4VHlwZSBuYW1lPSJwYWNrYWdlS2V5VHlwZSI+CiAgPHhzZDph
dHRyaWJ1dGVHcm91cCByZWY9InBhY2thZ2VSZWZHcm91cCIgLz4KPC94c2Q6
Y29tcGxleFR5cGU+Cgo8eHNkOmNvbXBsZXhUeXBlIG5hbWU9ImRlcGVkZW5j
eVR5cGUiPgogIDx4c2Q6YXR0cmlidXRlIG5hbWU9InR5cGUiIHR5cGU9ImRl
cGVuZGVuY3lLaW5kcyIgdXNlPSJyZXF1aXJlZCIvPgogIDx4c2Q6YXR0cmli
dXRlR3JvdXAgcmVmPSJwYWNrYWdlUmVmR3JvdXAiIC8+CjwveHNkOmNvbXBs
ZXhUeXBlPgoKPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJsaWNlbnNlVHlwZSI+
CiAgPHhzZDphdHRyaWJ1dGUgbmFtZT0idHlwZSIgdHlwZT0ibGljZW5zZUtp
bmRzIiB1c2U9InJlcXVpcmVkIiAvPgogIDx4c2Q6YXR0cmlidXRlIG5hbWU9
InZlcnNpb24iIHR5cGU9InhzZDpzdHJpbmciIHVzZT0ib3B0aW9uYWwiIC8+
CjwveHNkOmNvbXBsZXhUeXBlPgoKPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJw
cm92aWRlc1R5cGUiPgogICAgPHhzZDpzZXF1ZW5jZT4KICAgICAgIDx4c2Q6
ZWxlbWVudCBuYW1lPSJwYWNrYWdlX2tleSIgdHlwZT0icGFja2FnZUtleVR5
cGUiIAogICAgICAgICAgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9InVuYm91
bmRlZCIvPgogICAgPC94c2Q6c2VxdWVuY2U+CjwveHNkOmNvbXBsZXhUeXBl
PgoKPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJkZXBlbmRlbmNpZXNUeXBlIj4K
ICAgIDx4c2Q6c2VxdWVuY2U+CiAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0i
ZGVwZW5kZW5jeSIgdHlwZT0iZGVwZWRlbmN5VHlwZSIgCiAgICAgICAgICBt
aW5PY2N1cnM9IjEiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICA8L3hz
ZDpzZXF1ZW5jZT4KPC94c2Q6Y29tcGxleFR5cGU+Cgo8eHNkOmNvbXBsZXhU
eXBlIG5hbWU9InBsYXRmb3JtVHlwZSI+CiAgICA8eHNkOnNlcXVlbmNlPgog
ICAgICAgPHhzZDplbGVtZW50IG5hbWU9ImRlcGVkZW5jeSIgdHlwZT0iZGVw
ZWRlbmN5VHlwZSIKICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJz
PSJ1bmJvdW5kZWQiLz4KICAgIDwveHNkOnNlcXVlbmNlPgogICAgPHhzZDph
dHRyaWJ1dGUgbmFtZT0ibmFtZSIgdHlwZT0icGxhdGZvcm1OYW1lVHlwZSIg
dXNlPSJyZXF1aXJlZCIvPgogICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iYXJj
aCIgdHlwZT0icGxhdGZvcm1BcmNoVHlwZSIgdXNlPSJyZXF1aXJlZCIvPgo8
L3hzZDpjb21wbGV4VHlwZT4KCjx4c2Q6Y29tcGxleFR5cGUgbmFtZT0idmVy
c2lvblR5cGUiPgogICAgPHhzZDpzZXF1ZW5jZT4KICAgICAgPHhzZDplbGVt
ZW50IG5hbWU9InJlbGVhc2UtZGF0ZSIgdHlwZT0icmVsZWFzZURhdGVUeXBl
IiAvPgogICAgICA8eHNkOmVsZW1lbnQgbmFtZT0icGxhdGZvcm0iIHR5cGU9
InBsYXRmb3JtVHlwZSIgCiAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9j
Y3Vycz0idW5ib3VuZGVkIi8+CiAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJw
cm92aWRlcyIgdHlwZT0icHJvdmlkZXNUeXBlIgogICAgICAgICAgbWluT2Nj
dXJzPSIwIiBtYXhPY2N1cnM9IjEiIC8+CiAgICAgIDx4c2Q6ZWxlbWVudCBu
YW1lPSJkZXBlbmRlbmNpZXMiIHR5cGU9ImRlcGVuZGVuY2llc1R5cGUiCiAg
ICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIgLz4KICAgIDwv
eHNkOnNlcXVlbmNlPgogICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0icGtnX3Zl
cnNpb24iIHR5cGU9InBhY2thZ2VWZXJzaW9uVHlwZSIgCiAgICAgICAgdXNl
PSJyZXF1aXJlZCIvPgo8L3hzZDpjb21wbGV4VHlwZT4gICAgCgo8eHNkOmNv
bXBsZXhUeXBlIG5hbWU9InBhY2thZ2VUeXBlIj4KICA8eHNkOnNlcXVlbmNl
PgogICAgPHhzZDplbGVtZW50IG5hbWU9InN1bW1hcnkiIHR5cGU9InN1bW1h
cnlUeXBlIiAvPgogICAgPHhzZDplbGVtZW50IG5hbWU9ImRlc2NyaXB0aW9u
IiB0eXBlPSJkZXNjcmlwdGlvblR5cGUiIC8+CiAgICA8eHNkOmVsZW1lbnQg
bmFtZT0iY2F0ZWdvcmllcyIgdHlwZT0iY2F0ZWdvcmllc1R5cGUiIAogICAg
ICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAg
IDx4c2Q6ZWxlbWVudCBuYW1lPSJ2ZW5kb3IiIHR5cGU9InZlbmRvclR5cGUi
IAoJbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIgLz4KICAg
IDx4c2Q6ZWxlbWVudCBuYW1lPSJhdXRob3JzIiB0eXBlPSJhdXRob3JUeXBl
IiAKICAgICAgICBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0idW5ib3VuZGVk
IiAvPgogICAgPHhzZDplbGVtZW50IG5hbWU9ImxpY2Vuc2VzIiB0eXBlPSJs
aWNlbnNlVHlwZSIgCiAgICAgICAgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9
InVuYm91bmRlZCIgLz4KICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJ2ZXJzaW9u
IiB0eXBlPSJ2ZXJzaW9uVHlwZSIgCgltaW5PY2N1cnM9IjEiIG1heE9jY3Vy
cz0idW5ib3VuZGVkIiAvPgogIDwveHNkOnNlcXVlbmNlPgoKICA8eHNkOmF0
dHJpYnV0ZSBuYW1lPSJuYW1lIiB0eXBlPSJwYWNrYWdlTmFtZVR5cGUiLz4K
ICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJ1cmwiIHR5cGU9InBhY2thZ2VIb21l
VVJMVHlwZSIvPgo8L3hzZDpjb21wbGV4VHlwZT4KCjwhLS0gaW5zdGFudGlh
dGUgZG9jdW1lbnQgLS0+Cgo8eHNkOmVsZW1lbnQgbmFtZT0icGFja2FnZSIg
dHlwZT0icGFja2FnZVR5cGUiIC8+Cgo8L3hzZDpzY2hlbWE+CgoKCg==
--0-375289087-1000235081=:52800--
From rnd@onego.ru Tue Sep 25 08:21:53 2001
From: rnd@onego.ru (Roman Suzi)
Date: Tue, 25 Sep 2001 11:21:53 +0400 (MSD)
Subject: [Catalog-sig] metadata schema
In-Reply-To: <20010911190441.53237.qmail@web11604.mail.yahoo.com>
Message-ID: <Pine.LNX.4.30.0109251107370.5025-100000@rnd.onego.ru>
On Tue, 11 Sep 2001, Kapil Thangavelu wrote:
>attached is a xml schema for metadata. based loosely
>off osd, xsa and debian's control files. i stayed away
>from using namespaces for simplicity.
Last evening I was thinking about Catalog. It occured to me, that there
probably must be clear mathematical model of the Catalog.
It will give hard-to-beat informational and algorithmic
model almost automatically.
I know, that Catalog effort is lagging because of over-design (and that is
the reason why it is not quite there yet) but still this is very needed to
design it right.
I am sure that somewhere someone wrote nice dissertation on the topic of
storing and retrieving interdependent components (and probably on the
description of these data).
Software components aren't standing still. They fork, merge, split into
parts, join together in any proportions, etc., refactor in any thinkable
way.
And this data needs to be got based on the descriptions authors of the
components write (because who else will do it) for individual versions of
components.
Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd@onego.ru _/
_/ Tuesday, September 25, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ ""How to Catch Worms" by Earl E. Bird" _/
From k_vertigo@yahoo.com Tue Sep 25 09:51:28 2001
From: k_vertigo@yahoo.com (Kapil Thangavelu)
Date: Tue, 25 Sep 2001 01:51:28 -0700 (PDT)
Subject: [Catalog-sig] metadata schema
In-Reply-To: <Pine.LNX.4.30.0109251107370.5025-100000@rnd.onego.ru>
Message-ID: <20010925085128.87950.qmail@web11602.mail.yahoo.com>
--- Roman Suzi <rnd@onego.ru> wrote:
> On Tue, 11 Sep 2001, Kapil Thangavelu wrote:
>
> >attached is a xml schema for metadata. based
> loosely
> >off osd, xsa and debian's control files. i stayed
> away
> >from using namespaces for simplicity.
>
> Last evening I was thinking about Catalog. It
> occured to me, that there
> probably must be clear mathematical model of the
> Catalog.
> It will give hard-to-beat informational and
> algorithmic
> model almost automatically.
>
> I know, that Catalog effort is lagging because of
> over-design (and that is
> the reason why it is not quite there yet) but still
> this is very needed to
> design it right.
i've kinda given up on designing it right from the get
go, some things need to be tested by fire.
in an attempt to benefit from what others have done
before i've taken a look at alot of real world
implementations of package management and software
catalogs.
here's a sampling-
# package management
Yellow Dog Updater - http://sf.net/projects/yup
Gentoo Linux's Portage - http://www.gentoo.org
Debian's Apt
RPM
OpenACS's APM
OSD
# software catalogs
Sourceforge - http://sf.net/projects/alexandria
CPAN
Freshmeat
UDDI
i had planned on writing this stuff up on a public
wiki but zope.org apparently is transferring all of
its content to a cmf based version in a month...
>
> I am sure that somewhere someone wrote nice
> dissertation on the topic of
> storing and retrieving interdependent components
> (and probably on the
> description of these data).
actually there's another good parallel besides
software components. the catalog is very much parallel
to the webservices directory albeit with additional
client implentation and metadata requirements.
http://www.uddi.org
if you find a good dissertation please post a link.
cheers
kapil thangavelu
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
From guido@python.org Tue Sep 25 14:18:21 2001
From: guido@python.org (Guido van Rossum)
Date: Tue, 25 Sep 2001 09:18:21 -0400
Subject: [Catalog-sig] metadata schema
In-Reply-To: Your message of "Tue, 25 Sep 2001 01:51:28 PDT."
<20010925085128.87950.qmail@web11602.mail.yahoo.com>
References: <20010925085128.87950.qmail@web11602.mail.yahoo.com>
Message-ID: <200109251318.JAA13312@cj20424-a.reston1.va.home.com>
> i had planned on writing this stuff up on a public
> wiki but zope.org apparently is transferring all of
> its content to a cmf based version in a month...
AFAIK Wiki pages will still be supported and converted, so please
don't hesitate.
Otherwise, feel free to hijack a page of the (now largely unused)
Python 2.2 MoinMoin at http://www.python.org/cgi-bin/moinmoin/
--Guido van Rossum (home page: http://www.python.org/~guido/)
From k_vertigo@yahoo.com Sun Sep 30 01:08:42 2001
From: k_vertigo@yahoo.com (kapil thangavelu)
Date: Sat, 29 Sep 2001 17:08:42 -0700
Subject: [Catalog-sig] metadata schema
In-Reply-To: <200109251318.JAA13312@cj20424-a.reston1.va.home.com>
References: <20010925085128.87950.qmail@web11602.mail.yahoo.com> <200109251318.JAA13312@cj20424-a.reston1.va.home.com>
Message-ID: <200109292359.f8TNxQ091704@pimout4-int.prodigy.net>
On Tuesday 25 September 2001 06:18 am, Guido van Rossum wrote:
> > i had planned on writing this stuff up on a public
> > wiki but zope.org apparently is transferring all of
> > its content to a cmf based version in a month...
>
> AFAIK Wiki pages will still be supported and converted, so please
> don't hesitate.
ok, i've moved some content to a wiki on zope.org, its at
http://www.zope.org/Members/k_vertigo/Stories/Gideon/FrontPage
commenting open to all and editing open to zope.org members.
its a bit weak on a lot of substance... probably the most interesting thing
is the page on OtherSystems which still needs some fleshing out regarding
OSD/XSA metadata formats.
a data-model snapshot for postgres is also on the site at, its mainly a
scratch pad i've been using for outlining relational structure...
http://www.zope.org/Members/k_vertigo/Stories/Gideon/gideon-sql-snap.tgz
cheers
kapil
From k_vertigo@yahoo.com Sun Sep 30 01:25:51 2001
From: k_vertigo@yahoo.com (kapil thangavelu)
Date: Sat, 29 Sep 2001 17:25:51 -0700
Subject: [Catalog-sig] metadata
In-Reply-To: <00a001c1349d$f0374b70$ae03a8c0@activestate.com>
References: <20010831183938.51696.qmail@web11608.mail.yahoo.com> <00a001c1349d$f0374b70$ae03a8c0@activestate.com>
Message-ID: <200109300016.f8U0Gaw201706@pimout1-int.prodigy.net>
On Monday 03 September 2001 10:29 am, Andy McKay wrote:
> > I spent some time looking at the metadata of some
> > other packaging systems namely Debian's apt, ACS's
> > apm, and the OSD format.
>
> Yep, we use the OSD format quite well in the perl and python packager
> manager.
OSD does alot of things well, but i have some questions/concerns about it
and i'm also curious about active state's use.
- is activestate the only company currently using OSD?
- the use of version number seems very restrictive. there is an interesting
discussion of version numbers in the DistUtils Version.py file. i'm not sure
that enforcing a triple integer tuple of version numbers is realistic.
- the lack of depedency classification. packages might have different levels
of depedency ie SUGGEST/REQUIRES for example pygame.
- the explicit hardcoding of mirrors for codebase
- some of the values are a bit irrelevant to a python implementation like vm,
and memsize.
its obvious that osd was designed to be lean and mean for point and click
installs, i think that this might not nesc. bethe case, and i think its
important to support client specified levels of information. the information
going from a package uploader does not nesc. equal the one going to a client
downloading, since the catalog will need additional information for
classification purposes (although this could be catalog maintainer supplied).
but its also not evident that all clients will want the same level of
information, a sysadmin might want to view a changelog, while a newbie might
want a point and click install. i think the amount of metadata should be
flexible to the client's request and osd doesn't offer that much by way of
extended info (discounting additonal namespaces).
most of my concerns regarding OSD could easily be solved by altering the
format, i'm just curious how AS handles these things.
- in what way does PPD differ from OSD? is it just a trimming down of the more
esoteric features of OSD (mem, virtual machine,etc)?
- the use of depedency specification refers the client to another osd file,
without giving any indication of whats this represents? ie say i want to
install narval which requires pyxml v0.6. i have pyxml0.6 installed i
shouldn't have to grab another file without reason. the only alternative in
OSD is sometype of file naming convention which requires the client manually
parsing the url...
of course this brings up an interesting question that i'm unsure how to deal
with it. it applies more to the client and the server. namely how to deal
with conflicting depedency versioning requirements. say in the case above the
client has a newer version of a package than the requirements although the
narval package might require the older version. how does pyppm deal with this
on the client side?
> > something else i was considering is a some type of
> > global unique identifier to allow for replication of
> > information to different repositories. i was thinking
> > of something along the lines of a new uri protocol
> > that identified a package on the basis of its
> > clas sification with the catalog... i'm a little fuzzy
> > on this.
>
> You probably dont want to make it unique on the classification since that
> may change. CPAN uses
> authors, which isn't too bad but we will be a little less strict on that.
> Wouldn't the combination
> of package name and version be good enough and reasonably permanent?
my primary motivation for category based GUID was for replication purposes. i
see it more now as a uri reference to a codebase which will allow for use of
replicated servers, ie have /gui/pyqt be available from a number of
replicated servers. i should qualify my use of the phrase replication.
multi-master/peer-2-peer replication is hard, i think its probably easiest to
ditch this and go with a master-> slave setup ala cpan.
cheers
kapil thangavelu
From danm@ActiveState.com Sun Sep 30 03:25:45 2001
From: danm@ActiveState.com (Dan Milgram)
Date: Sat, 29 Sep 2001 19:25:45 -0700 (PDT)
Subject: [Catalog-sig] metadata
In-Reply-To: <200109300016.f8U0Gaw201706@pimout1-int.prodigy.net>
Message-ID: <Pine.LNX.4.30.0109291852080.32667-100000@latte.ActiveState.com>
> OSD does alot of things well, but i have some questions/concerns about it
> and i'm also curious about active state's use.
>
Let me preface by saying that the PPD format is based on OSD but isn't a
100% faithful rendition, and because it is an XML format it is
naturally subject to change.
> - is activestate the only company currently using OSD?
>
Hmm.. Not sure
> - the use of version number seems very restrictive. there is an interesting
> discussion of version numbers in the DistUtils Version.py file. i'm not sure
> that enforcing a triple integer tuple of version numbers is realistic.
>
I agree. And the version.py file has a good approach for comparing
versions - I think a lot of packages out there already adhere to version
strings as in the StrictVersion class. It seems reasonable to make this
the basis for allowable versions, and version comparison. The PPD format
for version strings is too restrictive in its current incarnation.
> - the lack of depedency classification. packages might have different levels
> of depedency ie SUGGEST/REQUIRES for example pygame.
>
In practice I think this distinction will be made by a very minor
fraction of packages out there. In any event this is easily solved by
adding a "LEVEL" attribute that defaults to REQUIRES if not there.
> - the explicit hardcoding of mirrors for codebase
>
This seems reasonable to me in this context
> - some of the values are a bit irrelevant to a python implementation like vm,
> and memsize.
>
Not in use...
> most of my concerns regarding OSD could easily be solved by altering the
> format, i'm just curious how AS handles these things.
>
> - in what way does PPD differ from OSD? is it just a trimming down of the more
> esoteric features of OSD (mem, virtual machine,etc)?
>
Pretty much. There's an additional PYTHONCORE element to specify the
language major minor version in order to handle pakcages with C extensions
> - the use of depedency specification refers the client to another osd file,
> without giving any indication of whats this represents? ie say i want to
> install narval which requires pyxml v0.6. i have pyxml0.6 installed i
> shouldn't have to grab another file without reason. the only alternative in
> OSD is sometype of file naming convention which requires the client manually
> parsing the url...
>
> of course this brings up an interesting question that i'm unsure how to deal
> with it. it applies more to the client and the server. namely how to deal
> with conflicting depedency versioning requirements. say in the case above the
> client has a newer version of a package than the requirements although the
> narval package might require the older version. how does pyppm deal with this
> on the client side?
>
It doesn't :( pyppm is somewhat immature and doesn't deal with
dependencies - this will be addressed by the
python 2.2 release. ppm - the perl variant - does handle dependencies.
Both versions maintain a cache or registry of sorts, so if a package has a
dependency the cache is checked and the dependent package only need be
downloaded if it isn't there. Dependent packages are specified with
explicit an explicit version number as an attribute. This isn't as
flexible as I'd like it to be. I don't know that there's a particularly
good way to handle packages which require older versions but I think RPM
and Deb packages are probably a better model to work off of eventually.
That said, I think we want to think about this in an evolutionary way -
there's only so much that can be tackled in the first go-around.
Regards,
Dan
--
Dan Milgram/ActiveState Developer
New! ASPN - ActiveState Programmer Network
Essential programming tools and information
http://www.ActiveState.com/ASPN