On Mon, May 06, 2002 at 08:27:45PM +0100, Mark Murray wrote:
> [ CC: list attacked with a machete ]
>
> Said Nicholas Clark <[EMAIL PROTECTED]>:
> > I think the furore was that by just removing CGI you broke our assumption
> > (or contract) - that if a perl says it's version N, then it comes with all
> > the library that version N shipped with.
>
> .... which is why I'm finding the split model so attractive.
Yes. If a job's worth doing, it's worth doing properly.
Break the contract with style. No half measures, please :-)
> > p5p: When we say perl version X, we mean both the interpreter and all
> > the libraries that were released in the source package for X.
> > Many scripts make assumptions about which modules are present based
> > on the version of the interpreter they are running under, and p5p
> > considers this supported behaviour. Hence we don't want scripts
> > (or users) to encounter something they think is perl version X
> > which doesn't have all the libraries, and doesn't say that it doesn't
> > fulfil this expectation of all the libraries
>
> But the split model will break this assumption?
Only if they think they're getting perl version X.
If it's clear they are not getting "perl version X" then it's their own
fault if they are unable to RTFM. Particularly if TFM tells them where and
how to get "perl version X"
> > Not sure how glob() works though. perl-borg would want to have /usr/bin/perl
> > do glob() with File/Glob.so
>
> So perl-borg can include it? What am I missing?
> > minimal perl wouldn't want File/Glob.so, but (I presume) would want glob()
> > to work.
>
> Not for us :-). And if folk wanted it, they would know where to get it.
> (Again, what am I missing?)
This bit of op.c:
#if !defined(PERL_EXTERNAL_GLOB)
/* XXX this can be tightened up and made more failsafe. */
if (!gv) {
GV *glob_gv;
ENTER;
Perl_load_module(aTHX_ PERL_LOADMOD_NOIMPORT,
newSVpvn("File::Glob", 10), Nullsv, Nullsv, Nullsv);
gv = gv_fetchpv("CORE::GLOBAL::glob", FALSE, SVt_PVCV);
glob_gv = gv_fetchpv("File::Glob::csh_glob", FALSE, SVt_PVCV);
GvCV(gv) = GvCV(glob_gv);
SvREFCNT_inc((SV*)GvCV(gv));
GvIMPORTED_CV_on(gv);
LEAVE;
}
#endif /* PERL_EXTERNAL_GLOB */
Whether a perl binary uses File::Glob instead of csh is a compile time
decision. (Currently). So it's not possible to make one /usr/bin/perl that
does glob() with File::Glob if possible, else fall back to csh.
As I understand it the ideal solution is one and the same /usr/bin/perl that
works stand alone to do FreeBSD's make world, but becomes the full perl when
the library package is got.
If none of the FreeBSD kernel scripts needs File::Glob (or if the kernel
does need glob but uses -I and provides a private version of File::Glob
either written in perl, or calling out to a shell) then I see no problem -
/usr/bin/perl is built to use File::Glob, kernel builds provide a perl
implementation, users are expected to get File/Glob.so by getting the perl
package.
> For the general information of the perl community:
>
> FreeBSD's "make world" happens in 3 stages (actually more, I am
> simplifying).
Thanks for the explanation.
On Mon, May 06, 2002 at 10:02:52PM +0200, Kay R�pke wrote:
>
> On Monday, May 6, 2002, at 09:27 PM, Mark Murray wrote:
>
> >But the split model will break this assumption?
>
> IMHO, yes it does. Whenever I see a perl binary which says "I'm Perl
> 5.X.X" I expect it to
> know at least the core perl library of the relevant release.
Whenever I see a perl binary I assume at least the core library of the
relevant release. If there is no warning that this is not the case,
so that my assumption is wrong, then the (implicit but well established)
contract has been broken.
If there is a warning notice that it's not what it might seem, then I
wouldn't consider it a breach of contract. The perl presented is effectively
a derived work (derived with use of 'rm')
I might be peeved that the full library wasn't there, but I wouldn't feel
conned.
So it *does* break the assumption; I agree with you.
Which is why I'd like it to be clear to FreeBSD (or elsewhere) users that
they can't make the assumption, so that no-one gets a nasty surprise.
> >Not for us :-). And if folk wanted it, they would know where to get it.
> >(Again, what am I missing?)
>
> I think the greatest trouble is to imagine to have a totally stripped
> down
> /usr/bin/perl without DynaLoader.
> Which makes it pretty hard to support all of perl's core functions.
> Again, I would have trouble to call that /usr/bin/perl.
I thought we'd managed to twist Mark's arm sufficiently that he was going
to include DynaLoader. If he doesn't, the I agree with you.
"This is perl. But you can't add any compiled extensions to it" wouldn't be
perl as we know it.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
