Avoiding The Vendor Perl Fad Diet

This looks like the standard set complaints made by most scripting language upstreams at most distributions, with the added complication that because so many distributions have essential core functionality that needs Perl, they want a minimal subset that supports that core functionality without including the entire distribution. Debian ships a "perl-base" which includes just enough Perl to run dpkg and other core utilities. (One of these days that might change, with more and more of those utilities rewritten in C, but it won't change anytime soon.)<p>While this post starts out with the classic "compile/install your own Perl" line that most other scripting language upstreams spout, it later reverts to the sensible position that distributions just need to provide some package which pulls in the full Perl distribution. That seems much more reasonable, and in fact most distributions do this. Debian provides the "perl" package for a full Perl distribution, and the "perl-base" package for the small subset that the core system needs.

It's such a shame that more and more languages are recommending to go this route.<p>The point of distribution packages once was that they would allow for easy updates of your environment without you having to go through the hassle of self-compiling whenever an update (security!) is required and to auto-install dependencies as needed.<p>But as time went on, the distribution packages became more useless for users and now the recommended practice is to practically leave the distributions packages alone and recompile everything you need (losing the advantages of free security updates).<p>Ruby, Python and now Perl.<p>It's not just the programming languages. It's also about users wanting latest versions of their day-to-day software. New Firefox comes out? Wait 6 months and update the whole OS to get it.<p>Maybe it's time for distributions to slim down considerably to the point where they really only contain everything that's needed for the system to run on its own.<p>All end-user software (with all their dependencies - disk space is cheap nowadays) would then be installed directly from the vendors - as it's done on every other OS on the planet.

There are two problems here: package management and version management. Package management is a wheel that has been reinvented a thousand times: every major distro has its own (yum, apt, pacman, portage), many modern programming languages have one (cpan, cran, pear, gems, cabal, npm) and also some applications (elpa for emacs). Sometimes even git is used as a package manager. This is a source of confusion ("should I install ruby via apt?"), conflicts ("I installed perl compiled from source, then I installed a package with my distro manager that pulled perl as a dependency. Which perl are my scripts using now?") and a general sense of unease ("software is spread all over my filesystem! argh!"). I wished that some common use case were found and unified under a unique software or library. Then there is version management. The linux ecosystem dealt with this for dinamic libraries with a common name scheme, soft links, and LD_LIBRARY_PATH. Then we have rvm for ruby and virtual env for python. These are not solutions, only hacks. I think that one of the root problem is that the unix model lacks something like namespaces. Hitting tab on my shell (under debian) suggests 2706 possible completions. This is not sustainable and hinders discoverability. &#60;/end rant&#62;

I am curious as to why the author doesn't mention how he has tried to bring this to the attention of the vendors, or just to Red Hat? For a problem that appeared <i>years ago</i> this seems a glaring omission.