One of the questions I asked about the pkg(1) project proposal was regarding the package format. I had some thoughts about this that I scribbled down a while ago, which are below. (This was in thinking about enhancing SVR4 packaging rather than replacing it.)
ZAP - Zip Archive Packaging =========================== Current SVR4 packages are delivered in 2 formats - filesystem and package datastream. How useful are these formats? When accessing a filesystem, packages in filesystem format clearly work. However, this format is inappropriate for networked delivery. Package datastream is delivered as a single file, which is easier to get from a network repository. However, the package datastream format itself isn't used elsewhere, requiring the use of the SVR4 packaging tools themselves to make sense of it. The basic requirement for network delivery is that we deliver a single file. What format should it be in? I suggest the following simple format: ZAP, or Zip Archive Package, a zip archive, in which a package (or multiple packages) is archived in what is essentially filesystem format witha additional metadata. Why is this good: - pkgtrans becomes simply zip and unzip - zip tools are widely available on other platforms, allowing users of those platforms to access the contents - you don't need new package tools - unzip gives you the old filesystem format (on old versions of Solaris, for example), although you lose the benefit of any extra metadata - following the jar extensions allow us to add packaging metadata - likewise for digital signatures - similar file formats are already used for signed patch delivery - we get compression for free - extending tools to read the packages ought to be simple; zip support is widespread - in particular, we can build a java interface easily The packages should contain the files laid out in the archive as they would be installed in the filesystem - they should not be placed inside another archive. Specifically, no more bz2 compressed cpio archives. (Simply storing the actual delivered files in this way also opens up the possibility of moving to a different packaging system - you just have to supply a diferent set of metadata.) In the case of multiple packages, we could deliver a package cluster as a single file. The metadata could also describe the cluster as a whole, rather than simply multiple packages supplied in a single file. The format should be efficient - compression minimizes the amount of data that needs to be transferred, while the cost of uncompression is low (certainly compared to bz2). Furthermore, most implementations allow a zip file to be opened and a file to be written directly to its destination with minimal overhead (no intermediate copies). Thoughts? Comments? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
