On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
> I put together a comparison table between par and rpm/jar.

You forgot deb, which I'd *much* rather deal with than rpm (if only
because I can point apt and dselect at CPAN).  You also forgot the "Is
Vaporware?" category. ;)


> | Available in a wide  |     Yes     |     No      |     Yes     |
> | range of platforms   |             | (Win32 +/-, |             |
> |                      |             | MacOS, VMS) |             |

Its going to be tricky getting par working under MacPerl.  It can be
done, but we're going to have to be very careful about what features
we use.


> | Supports binary,     |     Yes     |     Yes     |     No      |
> | source and bytecode  |             |             |  (source?)  |

par?  Binaries?  Bytecode?  Not until perlcc works, which won't be for
years if we assume it won't work until Perl 6.

> | Run from archive     |     Yes     |     No      |     Yes     |

This is going to be tricky to make efficient, especially with tar.gz
since we have to decompress the *whole* thing before we can pull
individual files out of the archive.  I don't think zip has this
problem.  Dunno about cpio or ar (which deb uses, I think).

I've been thinking about this... would dumping things into /tmp be
considered cheating?  Loading a Perl module from a filehandle might
screw with <DATA>.  And then resources (such as sounds, images,
etc...) will definately be expensive if we keep having to pull them
from the archive every time they're used.


> | Merge many archives  |     Yes     |     No      |     Yes     |
> | in one               |             |             |             |

???  What does this mean?

> | Usable with external |     Yes     |     No      |     Yes     |
> | tools (e.g. WinZip)  |             |             |             |

I don't know about WinZip, but we can use a CPAN shell style "poke
around and see what you've got"

> | Dependencies of      |     Yes     |     Yes     |     No      |
> | the archive          |  (included) |             |             |

Sure, but automatically finding those dependencies will be difficiult.
Closest I've yet seen is perl2exe, which often makes mistakes.  Java's
static nature makes it fairly easy.  rpm and deb have to explicitly
declare it, which they often get wrong.  Ditto CPAN modules.

We might be able to throw something together which scans for the easy
bits (ie. simple "use" and "require") recursively, and then warns if
it sees any C<eval STRING> in the code (or Module->require if
UNIVERSAL::require is involved).


> | Signed archives      |     No      |     No      |     Yes     |

Why not?  I was poking around inside a .jar yesterday and saw how they
do it.  Its pretty simple.  It'll be especially simple if CPAN starts
storing author's public keys.  This is something I'm going to retrofit
onto the CPAN shell anyway (err, someday).

We'll just have to use something other than RSA most likely.

Reply via email to