

Avoiding The Vendor Perl Fad Diet - Phra
http://www.modernperlbooks.com/mt/2012/01/avoiding-the-vendor-perl-fad-diet.html

======
JoshTriplett
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.)

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.

~~~
chromatic
_... it later reverts to the sensible position that distributions just need to
provide some package which pulls in the full Perl distribution._

Also if the base system installation requires Perl or another general-purpose
dependency, the distribution needs to keep the two forever separate.

------
pilif
It's such a shame that more and more languages are recommending to go this
route.

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.

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).

Ruby, Python and now Perl.

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.

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.

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.

~~~
bad_user
What I don't like about RPM / DEB repositories is that dealing with new
versions is hell-like.

I used Ubuntu 10.04 (the last LTS release) until this Sunday when I upgraded.
And I wanted Mono, but Ubuntu Lucid (a less than 2 years old version) comes
with Mono 2.4. And seriously, tons of improvements have been made between 2.4
and 2.10. For OS X you just go to mono-project.org and download / install the
latest package. That's it. No distribution upgrade necessary.

For Ruby the development in Ruby-land is so fast that trying to bundle the
latest JRuby or Rubinius would be a losing battle. And you also need packages
installed only for the current user, if only because devs constantly
experiment with beta-quality libraries and major versions have a habit of
breaking backwards compatibility. How are you going to solve that with DEBs or
RPMs?

And you could say that Linux distributions shouldn't have versions and just
upgrade stuff as soon as they are available. Well, as someone who lived for
several months with Debian Sid, I can tell you that's not such a good idea.

~~~
regularfry
> I used Ubuntu 10.04 (the last LTS release) until this Sunday when I
> upgraded. And I wanted Mono, but Ubuntu Lucid (a less than 2 years old
> version) comes with Mono 2.4. And seriously, tons of improvements have been
> made between 2.4 and 2.10. For OS X you just go to mono-project.org and
> download / install the latest package. That's it. No distribution upgrade
> necessary.

Mono is a special case, because quite a lot of apps which Ubuntu requires to
work depend on it. If you swap out the system Mono, many bets are off.
_However_ , the usual way to handle this situation is a project-specific
repository. If the upstream supplies an apt repository, or pushes to a
backports repo like badgerports, then you can install _just the version you
want_ without upgrading the rest of the system.

> For Ruby the development in Ruby-land is so fast that trying to bundle the
> latest JRuby or Rubinius would be a losing battle. And you also need
> packages installed only for the current user, if only because devs
> constantly experiment with beta-quality libraries and major versions have a
> habit of breaking backwards compatibility.

That's _precisely_ what RVM is for.

> How are you going to solve that with DEBs or RPMs?

You're not, and shouldn't try.

> And you could say that Linux distributions shouldn't have versions and just
> upgrade stuff as soon as they are available. Well, as someone who lived for
> several months with Debian Sid, I can tell you that's not such a good idea.

Looking in from the outside, it seems to work for Arch.

------
gosub
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. </end rant>

------
nodata
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 _years ago_ this seems a glaring omission.

~~~
chromatic
I didn't mention my discussions with vendors because those conversations
didn't go anywhere relevant.

