Larry Wall wrote:
I support the notion of distributing binaries because nobody's gonna
want to chew up their phone's battery doing unnecessary compiles. The
ecology of computing devices is different from ten years ago.
By binaries, I assume you mean native binaries, as opposed to Parrot
bytecode. The only problem I see is that it may be impractical to ask
CPAN mirrors to hold multiple binaries of each module for every OS and
every CPU.
On the other hand, distributing Parrot bytecode (or PIR, or PASM) seems
fine. But I don't know what to suggest for modules that require a C
compiler.
Most of these package managers have ways of running an installation
script at the end, so we could perhaps think of this as downloading
an installer rather than the actual software, and the new version
of the installer contains or has access to all the versions it knows
should be installed, and interacts with the official Perl library
installer to install them.
I suggested something similar to wayland76 a couple of days ago, to
solve a different problem. If I remember correctly, he was concerned
about the local package manager not knowing which files were installed.
Perhaps we should revisit this idea. This is what I proposed: We have
our own package manager (e.g. /usr/bin/cpan6 ) that takes a .tgz file
with an appropriate format:
/usr/bin/cpan6 install Foo-Bar.tgz
The RPM Foo-Bar.rpm would contain Foo-Bar.tgz and the rpm install script
would simply run "cpan6 install Foo-Bar.tgz". When the Fedora user
uninstall the module, rpm runs a script which just calls "cpan6
uninstall Foo::Bar".
By the same token, it's smart to keep the metadata close to the thing
it's describing, so if it's easy to extract up front reliably, that's
probably sufficient.
Yes.
Daniel.
