On Mon, Feb 12, 2001 at 05:28:04PM -0300, Branden wrote:
> Could you point me to some URLs? Like .deb file format? What's the good info
> the have? What's dselect? How it works?
Start from sections 6, 7 and 8 of the Debian FAQ
http://www.debian.org/doc/FAQ/
dselect, aptitude and several other utilities all work like the CPAN
shell, except its for Linux programs, utilities, libraries and kernels
(and perl libraries). It connects to a central repository (or
mirror), gets a listing of everything available, checks it against
what's already installed and gives you a nice listing. It can
automatically upgrade, install, find dependencies, find conflicts,
etc... for many thousands of packages (I have 1000+ packages installed
on my laptop, and that's just scratching the surface) and about a
dozen different architectures.
apt-get provides something similar to "perl -MCPAN -e 'install Module::Foo'"
> > 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.
Oh, of course it wouldn't be the 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!!!
Actually, its smaller than you'd think. From the little I've played
with perl2exe, it typically produces a 600-700K binary. This was for
a short program which only contained a few modules, but still. And
this was the demo version of perl2exe which doesn't try to save space.
Of course, I suspect its cheating and not using a static binary, but
assuming that certain Windows DLLs will be there. I don't know about
the Unix version of perl2exe.
> 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...
I agree, the situation sucks. Welcome to Windows. Trust me, I've
been bashing perl2exe for years (or rather, the comedy of errors which
leads to its necessity). Its only recently that I've had to deal with
a Windows office that its come in handy.
> SelfLoader could potentially be pre-processed the same way AutoLoader is...
That defeats the point of SelfLoader. AutoLoader sticks its routines
into individual files and then loads them from there as needed, but
reading files is potentially expensive. SelfLoader parses __DATA__
into a hash and evals them from there as needed.
AutoLoader is low startup cost for potentially high first run cost.
SelfLoader is for potentially high startup cost for low first run cost.
But they both do exectly the same thing externally.
Two options. One, just provide a bogus SelfLoader which is a subclass
of AutoLoader and run AutoSplit over the files anyway. IMHO the
performance difference between AutoLoader and SelfLoader will be
negligible compared to the cost of all this compression/decompression
and file reading going on.
Or, we could simply dup *DATA and stick the contents of __DATA__ into
another file (I think you suggested something similar). The only
problem there is if they attempt to use DATA to seek() back and read
in the original program. We can scan for that and warn about it.
Oh dear, I just had a horrible thought. Filters. Will Filter::exec
and friends still work with all this madness going on? Can we shove
Lingua::Romana::Perligata into a par??! A good pathological test
case, that.
> 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...
The Crypt::* modules on CPAN are all there. There are Crypt::RSA and
Crypt::IDEA floating around somewhere, haven't been posted on CPAN
because of legal issues. They have a fairly common interface, so its
not a problem.
Get away from this whole "standardize" notion. We're going to have
to abstract its usage internally anyway (there's already several ways
to do that with the Crypto modules) for design sanity, so we might as
well make it available to the user. For the start, we'll pick one
that's easy. In fact, we'll probably just call gpg or pgp to start
with for simplicity, then figure out a pure Perl version later.
Its unimportant.
