|| ||Tom Christiansen <tchrist-AT-perl.com> |
|| ||perl5-porters-AT-perl.org |
|| ||Re: Redhat perl != perl |
|| ||Thu, 13 Aug 2009 07:57:03 -0600|
|| ||demerphq <demerphq-AT-gmail.com>, Mark Mielke <mark-AT-mark.mielke.cc>,
John Peacock <john.peacock-AT-havurah-software.org>,
Ian Goodacre <Ian.Goodacre-AT-xtra.co.nz>,
brian d foy <brian.d.foy-AT-gmail.com>|
|| ||Article, Thread
SUMMARY: I below outline my own experiences with shipping Perl both in
whole and in part. I explain approaches I feel one should
*not* pursue and why not, as well as alternate strategies to
minimize potential troubles arising from shipping incomplete
(aka stripped or crippled or minimized) Perl distributions
when such cannot be avoided.
On Thursday, 13 Aug 2009, demerphq wrote at 10:35:39 +0200:
> Tom is out of line for implying malice when it is more likely to be
> lack of fore-thought.
> I think we have to be careful not to reverse the trick, he has a point
> about the naming IMO.
"Be not quick to attribute to malice something more easily
explained by ignorance or sloth--or both."
I don't blame the misleading naming and descriptions for the packages
on any secret or evil purpose. But neither do I call the site admin
incompetent who when told to install perl selects the most likely
package by name and description YET IT IS THE WRONG ONE, for that
blames the victim of the crime not the perpetrator.
> However, absent a guidance doc included with Perl I think the
> distributors are entitled to do what they wish.
There was once considerable resistance, or at least reticence, from
vendors about bundling Perl as part of their base utilities set.
It took many years before you could be reasonably assured that any
new system would already have Perl on it. You now can, or so I'd
come to think.
A couple of decades ago, I worked for the first hardware company to
include Perl as part of its base operating system utilities. We did
this because we needed Perl for running our own system checks (ie,
test suites) once a machine was put together by manufacturing.
It simply never occurred to us to ship anything less than whatever
perl5-porters had decided should go in the standard distribution;
ie, whatever "make install" installed. We needed some of the less
well-known nooks and crannies (eg, *.ph files for use by ioctl).
We certainly didn't care to make ourselves editors or arbiters of
what went into a Perl release. That's what perl5-porters was and is
doing; to countermand p5p's decisions would have meant a source
fork and a very serious commitment to eternal maintenance. It would
have served no one's good.
That said, times do change. On the one hand, Perl releases from the
early 90s were much smaller in the number and size of installed files
than today's releases provide. But on the other, systems today nearly
always provide a great deal more elbowroom on their disks than those did,
somewhat countering the larger storage requirements of modern Perl.
What irks me is that the justification for putting more and more in the
base Perl release, now including even amphibious modules, was that this
was the only way to get the most commonly desired functionality into the
hands of many end users who couldn't or wouldn't go messing around with
adding extras to their system. These people could depend only on the
standard distribution, not CPAN modules and such. So with nothing but
good intentions, we (=p5p) stuffed the release to try to help these
people, justifying our additions by their general usefulness and
increased system space available.
But why did we bother? For all that effort is now undermined, even
unravelled, if now vendors choose to strip down the real Perl distribution
by paring away pieces that we've decided to ship. I don't envy them their
positioning themselves as forkers, doomed to winnow and weed and forever
maintain, but that's their own problem. Worse is when they present this
stripped minidistro as the real thing. It's a misleading and confusing
state of affairs which should be discouraged.
I've also had experience with more than one company who shipped some
product that internally relied on a certain version of Perl, and so they
simply bundled the necessary parts of Perl with their product. However,
these companies *never* represented this partial distribution as a real
(or full, or proper, or complete, or standard) Perl installation. It
was always hidden away somewhere that their product could safely use
without any risk of interfering with anything that the OS vendor (eg,
/usr/bin) or the site admin (eg, /usr/local/bin) might install. You
simply don't go installing miniperl into /usr/bin/perl and those six
modules you need into /usr/lib/perl(5). That's a recipe for a heck
of a lot of trouble.
> So we should write a guidance doc. Once we have one, THEN we might
> have justification to complain.
Certainly it's better to submit a bug fix alongside one's bug report,
but one is always justified in complaining of actions that cause harm,
even if that harm is "only" one involving misunderstandings, be they
possible or probable. One does so to alert others of their peril; to
remain silent is worse.
Above I've outlined my own experiences with shipping Perl both in whole
and in part. I've explained approaches I feel one should *not* pursue
and why not, as well as alternate strategies to lessen potential troubles
arising from shipping incomplete/stripped/crippled Perl distributions *if*
this unfortunate situation just cannot be avoided.
I don't pretend that's all there is to it: there's more to address if
you want a guidance document to help bundlers make good decisions and
avoid bad ones. For one, you'll want to mention the inherent conflicts
from having a vendor-installed /usr/bin/perl and a site-installed
/usr/local/bin/perl. You probably also want to touch on conflicts or
confusions arising from having differing mechanisms for maintaining
package installation information (eg, CPAN's database vs that of
pkg_info or nasty not yummy RPMs) or in system-integrated documentation.
I bet there are matters I haven't even thought of, let alone through.
Most of all, I believe little more important than calling things what
they are *AND NOT CALLING THEM* what they are *not*. Careful naming
and careful descriptions are both critical to assure a stripped-down
Perl installation can never be confused with a full installation nor
*That* is what I was justly complaining about.
to post comments)