Since Gabor has disabled comments in his blog, I'll have to write in my own.
This is about Gabor Szabo's post about Perl application distribution.
There is a whole lot of things that need taking care of with a scheme like the one that Gabor outlines. The whole notion of managing dependencies gives me headache. In my experience, there are very few distribution schemes which work well (e.g. dpkg, CPAN) and many which don't work quite as well (various CPAN-alikes for other languages, PPM). Sometimes, it's a conceptual issue, sometimes just that such a beast carries a large technical and maintenance burden.
For example, I once created a PAR::Repository with (almost) the whole of CPAN in it. Took a horribly long time to generate... and was slow as molasses because of some technical issues. (In this case, it was a combination of large DBM::Deep databases and the dynamic dependency resolution of PAR::Repository::Client. It would be somewhat faster today.)
But Gabor suggests reducing this whole nightmare to a relatively "flat" dependency tree. It shifts parts of the problem to the developer of the app (need to include all dependencies which are not part of the platform) and eliminates some.
I could go on for ages about this and Gabor has had to suffer through that already, but what I really wanted to point out is that a tiny part is solved already: Soon, I'll release a tool that can install an arbitrary .par into an arbitrary perl installation on the system. That may sound simple enough, but I dare you to try install into a non-running perl using CPAN(PLUS). This means that you can just ship a single, binary executable that can install stuff if you just select the perl executable and the URI of the package to install. I hate bootstrapping.
