<[EMAIL PROTECTED]> wrote:
> 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.
>
Could you point me to some URLs? Like .deb file format? What's the good info
the have? What's dselect? How it works?
> 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.
>
Having a self-extractable wouln't allow perl using its own modules and
configuration files to decide how a `par'-file should be handled.
> 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.
>
Yes, useful, but I don't think this would be default. For this you would
need a statically linked Perl, and probably with all extensions linked in
too. And wouldn't be platform-independent. And it would be huge!!! And
extracting documentation from it would be a problem. And it wouldn't merge
with already existent Perl installation. And wouldn't be upgraded when
modules or perl itself is upgraded. And...
As you see, there are many reasons not to do this. Of course, there are many
more to do it, but I think we could leave them for `perl2exe'. If that's
very needed, we could add some parameters for `par' to do it, by including
the `par' archive to a statically-linked customized with-all-extensions
pre-built perl binary, to get the same result of `perl2exe', but I guess
that would yes be harmful for IndigoSTAR, and as _you_ said it, we don't
want to hurt them.
> > > 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.
>
With zip, wouldn't be necessary.
> > > 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.
>
SelfLoader could potentially be pre-processed the same way AutoLoader is...
If Perl 6 is sufficiently smart, and it'll probably be, it will let us
`hook' another tied filehandle into __DATA__, and so we'll be able to do
some crazy stuff to make this work. Maybe we `dup' the filehandle that's
reading the file when __DATA__ is found, and we read from it (decompressing
on-the-fly) until we reach __END__, in which case we know we are at the
beginning of the data. Admitedly not efficient at all, but as said before,
efficiency is not the real objective of it, and we have many ways to work
around this.
> > > > | 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.
Yes, but this is something `par' is expected to do. For example, suppose I
wrote a script foo.pl that requires Bar.pm and Baz.pm. I could go to CPAN,
and download Bar-1.0.noarch.par and Baz-3.54.noarch.par. Then I could
par -o ../foo-1.3.noarch.par ./bin/foo.pl ../Bar-1.0.noarch.par
../Baz-3.54.noarch.par
And `par' would automatically handle them for me. The main use of it is when
Bar/Baz was platform-dependent, so that I could build various foo pars, one
for which platform, only by having Bar/Baz pars for all those platforms.
> 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).
>
For par in Perl5 (pp5), I suggest we don't handle versions. Perl 6 will
probably have a mechanism of its own to handle it, so if we only use it,
we'll be OK.
> > > > | 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.
Are there already modules that handle this (RSA/IDEA/...) ? Perhaps we'll
also want them to share the same interface so that we can do it flexible as
well... For this one I don't know if we could support different key formats
or if we should standardize on one...
- Branden
