I think this would be rad:
- PPM becomes part of the perl core
- All CPAN packages are built to into PPDs automatically on common
platforms
- PPM is extended to allow installing into non-root locations
This would allow non-perl people to install perl packages much easier,
without having to mess with the CPAN shell and running tests. It
would also make installing CPAN packages into hosted environments much
easier.
Any thoughts?
I think this would be incredibly bad, and a clear example of premature
optimisation.
If CPAN is installation from source, then binary packages will depend
VERY heavily on the environment they are built in.
With many many modules needing various external libraries in order to
work, that integration needs to be done by the package management system
of each environment.
That means while PPMs work file on ActivePerl, they may NOT other place.
The only guarantee the ActiveState PPM library provides for example is
that it will work within ActivePerl.
The same "binary" package doesn't work in different environments in any
other language, and it doesn't work for us either.
Binaries need to be built for Debian, or FreeBSD, or ActivePerl or
whatever, it would be greatly overstepping our (the Perl language)
mandate to dictate some form of standard packaging system for Perl
applications that differs from the native packaging system for that
environment that Python and C and C++ and Ruby and Scheme and Lisp and
everything else uses.
It's appropriate for ActiveState to build PPMs against the ActivePerl
environment. It's not appropriate for us to do it in core Perl.
What I'd like to see instead is suggestions on ways that we can improve
Perl packages to make it easier for the various auto-packaging systems
to do their job.
If a Perl module needs libfoo then it should be stated in the metadata
somewhere so that the binary packaging system can resolve that
generalised dependency into the appropriate action for that environment.
Adam K
