From owner-freebsd-ports  Sun Nov 10 10:14:38 1996
Return-Path: owner-ports
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA22614
          for ports-outgoing; Sun, 10 Nov 1996 10:14:38 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA22607
          for <FreeBSD-Ports@freebsd.org>; Sun, 10 Nov 1996 10:14:34 -0800 (PST)
Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id KAA27901; Sun, 10 Nov 1996 10:14:28 -0800 (PST)
To: obrien@NUXI.com (David E. O'Brien)
cc: FreeBSD-Ports@freebsd.org
Subject: Re: blt2.1 
In-reply-to: Your message of "Sun, 10 Nov 1996 09:57:38 PST."
             <199611101757.JAA17414@relay.nuxi.com> 
Date: Sun, 10 Nov 1996 10:14:28 -0800
Message-ID: <27899.847649668@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-ports@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> Do you have a plan for this now?  Will it be Makefile var dependent or a
> more incompassing method?  This sounds neat!

Far more encompassing.  The only hold-up in actually starting this
project up to now has been the fact that I don't have a reasonable
library for handling ZIP files, which I've chosen as the next
generation packaging scheme's file format.  ZIP files give good random
access to data with compression, and they're _standard_ which means
that you can pick them apart and look them over, if you wish.  A lot
of people have made it very clear that I'd be hung from a flagpole if
I went to some custom file format, ala Red Hat's RPMs, so I had to
choose something fairly common.  Out of ZIP, ZOO or ARC, I think
ZIP is the best choice.

In any case, it finally occurred to me (with a loud accompanying
"duh!")  last week that I don't have to make the lack of a ZIP access
library such an impediment to progress, I can simply write the API to
some hypothetical interface spec and then keep the "zip files" as
actual directories with the entries as files.  This will make it easy
to monitor the "insides" of a package file during testing and also let
work continue past the zip API problem until we have a chance to go
back and implement that piece.

In any case, this is a 3.0 project since I won't have a chance to do
squat until we've gotten 2.2R and 2.1.6R off the ground.

						Jordan