Re: vendor_perl

[Andy Dougherty <doughera@lafayette.edu>]

On Mon, 17 Jan 2000, Tom Christiansen wrote:

> Could anyone please tell me whether any vendors are currently
> using the vendor_perl hook?  If so, could you please send me 
> an @INC dump like this:

I doubt anyone's using it yet because it isn't really implemented yet.
That is,

	perl Makefile.PL INSTALLDIRS=vendor

hasn't been implemented yet.

Also, it's only in recent development versions (5.005_6x and on, or so),
and I doubt any vendor's distributing unstable development versions.

Also the searching across versions hasn't been implemented yet (though
some progress has been made), so it won't work as described in INSTALL.

Also, if some of the searching across versions stuff works out as it
appears it might, then the vendorlib idea needs to be revisited, as it
might not be necessary.  (In some ways, vendorlib stuff was a partial
substitute for searching across earlier versions because it allowed a
vendor to put stuff somewhere where it could be found by multiple
versions.  I proposed it because I knew I personally wouldn't have time to
implement and test searching across versions.  I still don't.  However, I
was subsequently convinced that the searching across versions scheme was
better and that someone else would step up and implement it.

Also (and somewhat independently, but somewhat related as we try to reign
in the apparent hopeless complexity of @INC) there is the question of
whether an additional set of directories is needed.  At a quick glance, it
looks to me like the OpenBSD folks are doing something similar to what the
Rhapsody folks have done, and to something Jarkko has proposed, namely
introduce *2* "site" libraries, one, such as the current $sitelib, which
might be some sort of company-wide shared network directory, and a second,
$locallib possibly on a local disk.  To quote from Jarkko's relevant
metaconfig unit:

    This differs from $sitelib in that $sitelib is often
    a shared network directory while $locallib may be
    on a local disk, because of policy/administrative issues
    like for example caching (performance), licensing, or security.

> I notice that OpenBSD 2.6 uses its own ideas of vendor_perl, but
> doesn't exactly call it that.  Part of what they're doing at OpenBSD,
> BTW, it making sure that all the *.ph files are there--without
> which, standard modules like Sys::Syslog and standard functions
> like syscall(), won't work.

Yes, that's a nice thing for a vendor to do when packaging a perl binary.
It used to be that h2ph was simply too unreliable (or, putting it another
way, vendors were too unreliable and kept changing headers in ways that
confused h2ph) so that we couldn't have installperl run h2ph by default
unless we were prepared to deal with torrents of bug reports and
complaints.  I haven't paid attention to this issue in several years,
however.  Perhaps Kurt's work on h2ph has brought us to the point where
it's worth reconsidering.  (Not so much to support the core distribution,
which could be changed to not need h2ph, but to support other existing
programs.)

    Andy Dougherty		doughera@lafayette.edu
    Dept. of Physics
    Lafayette College, Easton PA 18042

---

References to:

Tom Christiansen <tchrist@chthon.perl.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---