[Catalog-sig] metadata

[kapil thangavelu]

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