Sat, 29 Sep 2001 17:25:51 -0700
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
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,
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.