[EMAIL PROTECTED] wrote:
> 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. ;)
>
I don't really see much _conceptual_ difference between rpm, deb, and the
other package formats used by Linux. I think all of them suffer from the
platform-specific problems, since I know they're not available/easy to
install/stable/solid on non-UNIX platforms. Porting them would probably be
much harder than building something that meets our needs from scratch.
>
> 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.
>
I guess not. It will probably use only the `plain' features of underlying
archive format (no special data or info attached to files, only default
compression methods, ...). This means it will basically need only zlib
(which AFAIK is very portable, inclusive to Macs), and Archive::Zip that
only parses the file format, which is probably also portable. Filenames
(which are also a problem for Macs) can be translated by par/pun to a
standard naming. I don't know, are these the problems with MacPerl you're
talking about ?
>
> > | 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.
>
I see no problem, since this is perl6-language...
I really think par/pun are Perl 6 things. I realise module distribution with
Perl 5 is nasty, but I really don't think we can do something about it now.
IMO, if it's not shipped with Perl, most layman users won't have it, and
that defeats most of its purpose. Get it into Perl 5.8 (when it gets the
street) is valid to a certain point, but not every user would get it...
> > | Run from archive | Yes | No | Yes |
>
> This is going to be tricky to make efficient,
I guess that's not meant to be efficient. I propose it so that:
1) You can try to run it to see if you like it before you install it
definitely.
2) One application can download an archive from Internet and run it inside
its own environment (s/application/browser/ and you have an applet).
> 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).
>
That's why zip is my choice.
> I've been thinking about this... would dumping things into /tmp be
> considered cheating?
Probably not, but avoiding it would be appreciated (for the objectives
above -- consider a diskless machine).
> Loading a Perl module from a filehandle might
> screw with <DATA>.
As resource files can be attached to the archive, I think not allowing
__DATA__ wouldn't be such a big restriction. I don't know if we can find
other workarounds.
> 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.
>
Actually, if you read a resource file more than once, you're paying the
price of it. Of course decompressing it more than once is more expensive,
but I think that's probably not such a big price to pay for it. As I said,
it doesn't need to be efficient, because installed ones will certainly be.
The `Resource' module that provides access to resouces in the archive could
also be told to cache the resources in memory/disk, so this problem would be
circumvented.
>
> > | Merge many archives | Yes | No | Yes |
> > | in one | | | |
>
> ??? What does this mean?
>
Take some scripts and lots of .par (containing modules needed by the
scripts) and make all this directly into one .par, without needing for
having the .pars uncompressed somewhere.
> 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).
>
Exactly what I would propose.
>
> > | 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).
>
Well, you'll probably help me with this, if that's OK with you. Could you
send me some text/URLs saying how it works so that I can figure out one way
to do it and include it in the PDD. If you want to do it yourself, pick the
alpha version of the PDD in this same list and do it.
I don't know about the granularity of jar's signing. Remember here we'll
probably have several scripts and several modules inside the same archive,
and potentially each one would have a different signature. Is this possible?
> We'll just have to use something other than RSA most likely.
>
Why? Problems with exporting cryptosystems? If that's it, how does
Java/Netscape do it?
- Branden
