On Mon, Feb 12, 2001 at 04:01:31PM -0300, Branden wrote:
> I don't really see much _conceptual_ difference between rpm, deb, and the
> other package formats used by Linux.
debs store alot of information that rpm doesn't, and it would be good
to look at to steal good ideas. Also, and most importantly, they have
dselect, which is similar, but much more powerful, than CPAN and the
CPAN shell. That's something to look at.
> I don't know, are these the problems with MacPerl you're
> talking about ?
Yeah, just alot of little things.
> > 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
Ever made a self-extracting archive? Its just a zip file attached a
little unzip binary. Send that to someone, they run it and it
decompresses itself! chicken<->egg.
par can do something similar. It can slap a copy of pun (and thus
perl) onto the archive. Its not simple, and its platform dependent,
but its useful. I'm more and more seeing par as a way of
embrace/extend/destroying perl2exe.
And I think we could squeeze something into 5.8.
> > 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).
Ok, we can have some flags and configuration bits figure that out.
> > 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.
This kills SelfLoader and unsplit AutoLoader modules and similar
schemes. AutoLoader isn't so much a problem, since we can just run
AutoSplit over it. SelfLoader will be tricky.
> > > | Merge many archives | Yes | No | Yes |
> > > | in one | | | |
>
> 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.
Heh, simplest way to do that is to cheat and just decompress all the
pars and put them back together. There will be problems, for
instance, with two pars that use the same modules but different
versions. Default behavior might be to use the newest version and
throw a warning. Otherwise our par could have several different lib/
directories. For instance:
lib/ contains the unconflicting modules
lib/CGI-2.49/ contains version 2.49 of CGI.pm
lib/CGI-2.62/ contains version 2.62 of CGI.pm
And then scripts which need 2.49 can be run with "perl -Ilib/CGI-2.49"
and the other with "perl -Ilib/CGI-2.62".
This is ok for running from within the par, but installing will get
tricky under perl5. perl6 will presumably have something to solve
this (as noted in the recent lengthy discussion).
> > > | Signed archives | No | No | Yes |
>
> 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.
Oh, I'm the last person to ask about crypto. I don't even know how to
use pgp. I just peeked into a jar and saw how they did it.
Basically, they have a manifest file like:
Manifest-Version: 1.0
Main-Class: bsh.Console
Name: bsh/lib/defaultImports
Digest-Algorithms: SHA MD5
SHA-Digest: 20px9AdMKT+bm//JCDSIaMVES/c=
MD5-Digest: j+s36wWf8zHghz5I8jxURQ==
Name: bsh/lib/javaPackages
Digest-Algorithms: SHA MD5
SHA-Digest: y52XNqru6tU8BXGybyzJ7Gvy49g=
MD5-Digest: q7Z7lIxNwxmKVXMBeEiN4A==
and then there's another file for storing RSA information, that's a
bit more complicated. However, I figure tacking a pgp or gpg
signature onto each package in the manifest wouldn't be too hard.
> > 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?
Actually, the RSA patent just expired, didn't it? Even gpg has it.
Ok, then maybe we can use RSA. OTOH, IDEA is right out.
As for export, the US recently relaxed its laws, especially relating
to Open Source projects (maybe because they assume no bunch of
unfunded geeks could out-think the NSA ;)
http://www.crypto.com/exports/, http://www.cdt.org/crypto/ and
http://www.cdt.org/crypto/admin/
Again, this is just like the compression format. Its all flexible,
its not really important.
