[plt-scheme] Unix install

On May  4, Lauri Alanko wrote:
> But anyway, if you want concrete suggestions, the jar/xpi approach
> seems best to me: use zip as the archive format, and store metadata
> in some specially named files within the archive. For direct
> duplication of the current .plt organization, there might be two
> files named e.g. "pkg-info.ss" and "install.ss". Admittedly zip is
> not the prettiest format on earth, but it's probably the most
> ubiquitous and best supported. More so than tar or StuffIt, anyway.

The problem is the code that will deal with zip files.


> I really think that ASCII armoring should only be done as a separate
> step that is not tied tightly with the actual archive format, but if
> files are still to be distributed as base64, the data just needs
> some sort of a header. Unfortunately base64-coding of static files
> is so rare that it hasn't been standardized very well. I suggest
> using either the uuencode way:
> [...]

(Ugh...)

> Or making the file an actual MIME document:
> [...]
> The latter approach is more extensible, although use of MIME in
> plain files is rather unorthodox.

Yes, it's definitely better in that you can use hooks for possible
future extensions of different encodings and other format data.  (SVN
uses it in a reasonable way for repository dumps.)


> The implementation difficulty depends on requirements. There's lots
> of free software for manipulating zip files, and of course the
> simplest way would be to just call "zip" and "unzip" when needed
> (possibly distributing versions of those to ensure that they are
> available everywhere).

This seems to be the major obstacle.  Using a zip/unzip executables is
not a good solution for something as sensitive as installations.


> Tighter integration with scheme code (scheme bindings for C
> libraries, or a new, purely Scheme-based zip library) would be a bit
> more work.

Same problem.  I agree that the zip format is generally better than
gzipped private format -- but given that gzip is easier to deal with
and that the code is there, my vote goes for sticking with the current
format.  (Which, as Matthew pointed out, is fully documented, I
actually used it for other purposes since years ago.)


On May  3, Dave Herman wrote:
> 
> FWIW, I have a zip file manipulation library in PLaneT that anyone
> is welcome to rip off.
> 
>      http://planet.plt-scheme.org/#zip.plt2.1

But once you put stuff in zip format, the library must be able to deal
with any zip format -- looking at your docs, it deals only with one
compression type, which will fail when people start tinkering around
with these zip files.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!