Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-02 Thread Hellmuth Michaelis

From the keyboard of M. Warner Losh:
 My take on this.  We should remove perl from the base, and
 automatically install the port for most users in sysinstall, just like
 we do with XFree86.

OK, fine and if then an option FETCH_MAKE_AND_INSTALL_PERL_FROM_PORTS
is added to make.conf and made working so that make buildworld/installworld
updates go transparenly without loosing perl (or any other component of the
current base system, which will for shure be removed taking the perl
removal as a precedent case) then i'm calmed down.

In other words: this move from the base to the ports has to go unnoticed
to the user for _all_ methods of installing and updating - IMHO otherwise
FreeBSD will get real problems since perl (and what is currently in the 
base system - including gcc/gdb/etc and even sendmail :-) ) is considered
an integral part of a base contemparary operating system by the user base
(including sysadmins who are only _using_ FreeBSD).

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-02 Thread Mark Murray

 From the keyboard of M. Warner Losh:
  My take on this.  We should remove perl from the base, and
  automatically install the port for most users in sysinstall, just like
  we do with XFree86.
 
 OK, fine and if then an option FETCH_MAKE_AND_INSTALL_PERL_FROM_PORTS
 is added to make.conf and made working so that make buildworld/installworld
 updates go transparenly without loosing perl (or any other component of the
 current base system, which will for shure be removed taking the perl
 removal as a precedent case) then i'm calmed down.

This won't work - perl won't cross-build.

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-02 Thread Mark Valentine

 From: [EMAIL PROTECTED] (M. Warner Losh)
 Date: Thu 2 May, 2002
 Subject: Re: Save a few hunderd kilobytes or a few hundred perl users?

 My take on this.  We should remove perl from the base, and
 automatically install the port for most users in sysinstall, just like
 we do with XFree86.

XFree86 doesn't stomp on /usr/local (nor does the other port semi-
automatically installed via sysinstall, linux_base).

As part of the process of packaging the base system, I support the
idea of a new type of more tightly integrated package, installed in
/usr (for the core packages) or /usr/{opt,pkg,contrib}.  ports
would remain as they are, though (seems too late to reclaim
/usr/local if you ever want to use those...).

Cheers,

Mark (sole member of the Reclaim /usr/local Campaign).

-- 
Mark Valentine, Thuvia Labs [EMAIL PROTECTED]   http://www.thuvia.co.uk
Tigers will do ANYTHING for a tuna fish sandwich.   Mark Valentine uses
We're kind of stupid that way.   *munch* *munch*and endorses FreeBSD
  -- http://www.calvinandhobbes.com  http://www.freebsd.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users

2002-05-02 Thread Kenneth Culver

 The base will no longer depend on it before too much longer.  The vnode
 and kobj dependencies are already gone in current.

Ahh, ok, if that's the case, then I agree with your original statement;
not that it matters much :-)

Ken


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Mark Murray

 NetBSD (-current, at least) does not have perl in the base.  OpenBSD
 has 5.6.something.

*NOD*

 Perhaps FreeBSD could benefit from following NetBSD, and use awk or
 whatever to replace the perl stuff for kernel build and wherever else.

We've already sorted that out for the kernel build. I'm going to see
how well miniperl works for the userland perl scripts.

 People who actually want perl could then install a miniperl package
 and as many modules as they need or like, up to and including the very
 latest full-bloat^H^Hwn version, if desired.

I reckon we'll keep miniperl for a while.

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Vadim Konovalov

 I'm not sure that is acceptable. I believe that perl 5.8.0 will be
 +- 45 MB. I cannot afford to import all of that - I'd get lynched.

that is price, for example, for Unicode.
Okay, when many platforms will be doing stripping their tools, everyone
should remember where his perl programs are able to run and where they are
not and require additional dowloading. (I remember how I was disappointed
that Redhat linux distribution did not contained Tk in its distribution,
even for optional installation. It was a pain to rebuild)

For me, nowadays 45MB is nothing compared to medium HDD capacity, and even
my POCKET PC will easily accomodate it...

Vadim.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Johan Vromans

Johnny Lam [EMAIL PROTECTED] writes:

   perl-5.10.0
   perl-library-standard-1.0
   perl-library-ISP-1.0
   ...

Whatever approach we take, two major problems must be solved to
accomplish this:
 1: A perl distribution must be able to be (re)located anywhere and
use itself as a starting point to find its additional libraries
and modules.
The way ActiveState's rpm handles it (by patching the binaries and
scripts) works, but defeats the rpm functionality to verify an
installation.
 2: Add-on modules (base-perl and site-perl) must be able to fit
themselves into an existing perl installation so they can be
distributed in prebuilt form.

In short, we need componentized, prebuilt distributions.

Is this being worked on already?

-- Johan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Hugo van der Sanden

Johan Vromans [EMAIL PROTECTED] wrote:
:Johnny Lam [EMAIL PROTECTED] writes:
:
:  perl-5.10.0
:  perl-library-standard-1.0
:  perl-library-ISP-1.0
:  ...
:
:Whatever approach we take, two major problems must be solved to
:accomplish this:
: 1: A perl distribution must be able to be (re)located anywhere and
:use itself as a starting point to find its additional libraries
:and modules.
:The way ActiveState's rpm handles it (by patching the binaries and
:scripts) works, but defeats the rpm functionality to verify an
:installation.
: 2: Add-on modules (base-perl and site-perl) must be able to fit
:themselves into an existing perl installation so they can be
:distributed in prebuilt form.
:
:In short, we need componentized, prebuilt distributions.
:
:Is this being worked on already?

Not that I'm aware; volunteers welcome.

Hugo

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Johan Vromans

[Quoting Hugo van der Sanden, on May 1 2002, 15:06, in Re: Save a few hunde]
 Johan Vromans [EMAIL PROTECTED] wrote:
 :Whatever approach we take, two major problems must be solved to
 :accomplish this:
 : 1: A perl distribution must be able to be (re)located anywhere and
 :use itself as a starting point to find its additional libraries
 :and modules.
 :The way ActiveState's rpm handles it (by patching the binaries and
 :scripts) works, but defeats the rpm functionality to verify an
 :installation.
 : 2: Add-on modules (base-perl and site-perl) must be able to fit
 :themselves into an existing perl installation so they can be
 :distributed in prebuilt form.
 :
 :In short, we need componentized, prebuilt distributions.
 :
 :Is this being worked on already?
 
 Not that I'm aware; volunteers welcome.

Okay, I'll bite.
Who joins?

-- Johan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Mark Murray

  I'm not sure that is acceptable. I believe that perl 5.8.0 will be
  +- 45 MB. I cannot afford to import all of that - I'd get lynched.
 
 that is price, for example, for Unicode.
 Okay, when many platforms will be doing stripping their tools, everyone
 should remember where his perl programs are able to run and where they are
 not and require additional dowloading. (I remember how I was disappointed
 that Redhat linux distribution did not contained Tk in its distribution,
 even for optional installation. It was a pain to rebuild)
 
 For me, nowadays 45MB is nothing compared to medium HDD capacity, and even
 my POCKET PC will easily accomodate it...

45 MB is fine as a port - we have ports that are way bigger than that.

As part of the base OS? Nope. The only functionality that we _need_
is the basic language - effectively miniperl.

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Jarkko Hietaniemi

Debian's perl-base is a little bit more than miniperl but it still is
only 1.2MB (ix86).

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Dan Kogai

On Thursday, May 2, 2002, at 12:56 , Mark Murray wrote:
 For me, nowadays 45MB is nothing compared to medium HDD capacity, and 
 even
 my POCKET PC will easily accomodate it...

 45 MB is fine as a port - we have ports that are way bigger than that.

And we even have bigger ports that does take longer to build than 'make 
buildworld' the whole FreeBSD (which takes less than 30 minutes on 
Athron XP 1400 -- the fastest box I have at my fingertip).

 As part of the base OS? Nope. The only functionality that we _need_
 is the basic language - effectively miniperl.

But to sensibly strip down the distribution to just as much as needed 
does take a lot of something the most precious -- intellectual power.  
That I consider a waste.  I don't think anyone objects that there are 
several hundred, or even thousand, files under /usr/src so long as it 
builds and so long as it nicely fits -- say, in a CD-ROM.  FreeBSD 
4.5-stable as of now is just 364,149 kBytes UNCOMPRESSED.  Why don't you 
just untargz what Perl 5 porter has to offer and forget about what files 
should go and stay?  You can easily install only needed parts.

Speaking of which, the whole build process does not use objective-C 
(correct me if I am wrong).  So if you insist on stripping Perl it may 
as well be unfair to leave GCC unstripped (I pretty much doubt GPL 
allows you to do so, however).

Dan the Wanted for Bloating Perl 5.8


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Jarkko Hietaniemi

 But to sensibly strip down the distribution to just as much as needed 
 does take a lot of something the most precious -- intellectual power.  
 That I consider a waste.  I don't think anyone objects that there are 
 several hundred, or even thousand, files under /usr/src so long as it 
 builds and so long as it nicely fits -- say, in a CD-ROM.  FreeBSD 
 4.5-stable as of now is just 364,149 kBytes UNCOMPRESSED.  Why don't you 
 just untargz what Perl 5 porter has to offer and forget about what files 
 should go and stay?  You can easily install only needed parts.

Well, my understanding is that this is exactly what Mark is talking
about-- for the needs of the FreeBSD itself (build, pksrc?) they don't
need all of Perl.  For that miniperl or something like Debian's
perl-base where you don't start by leaving out what you don't need but
instead by taking in only what one absolutely needs.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Mark Murray

 On Thursday, May 2, 2002, at 12:56 , Mark Murray wrote:
  For me, nowadays 45MB is nothing compared to medium HDD capacity, and 
  even
  my POCKET PC will easily accomodate it...
 
  45 MB is fine as a port - we have ports that are way bigger than that.
 
 And we even have bigger ports that does take longer to build than 'make 
 buildworld' the whole FreeBSD (which takes less than 30 minutes on 
 Athron XP 1400 -- the fastest box I have at my fingertip).
 
  As part of the base OS? Nope. The only functionality that we _need_
  is the basic language - effectively miniperl.
 
 But to sensibly strip down the distribution to just as much as needed 
 does take a lot of something the most precious -- intellectual power.  

Nope - it is trivial. We already make miniperl. We just need to install
it and not install the rest of perl. 10 mins to do the work, and on-and-off
fiddling to make the world build complete.

M

 That I consider a waste.  I don't think anyone objects that there are 
 several hundred, or even thousand, files under /usr/src so long as it 
 builds and so long as it nicely fits -- say, in a CD-ROM.  FreeBSD 
 4.5-stable as of now is just 364,149 kBytes UNCOMPRESSED.  Why don't you 
 just untargz what Perl 5 porter has to offer and forget about what files 
 should go and stay?  You can easily install only needed parts.

Bloat.

Its easy to rm -rf stuff where stuff != unix, and other simple
rules.

 Speaking of which, the whole build process does not use objective-C 
 (correct me if I am wrong).  So if you insist on stripping Perl it may 
 as well be unfair to leave GCC unstripped (I pretty much doubt GPL 
 allows you to do so, however).

We strip GCC. We strip most things that we install in src/contrib.

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Andy Dougherty

On Wed, 1 May 2002, Jarkko Hietaniemi wrote:

 Well, my understanding is that this is exactly what Mark is talking
 about-- for the needs of the FreeBSD itself (build, pksrc?) they don't
 need all of Perl.  For that miniperl or something like Debian's
 perl-base where you don't start by leaving out what you don't need but
 instead by taking in only what one absolutely needs.

[I have removed perl5-porters from the CC list since I don't think that's
necessarily the best forum to give unbiased advice about balancing
different needs in setting up the base FreeBSD system :-).  Also, it was
seeming to generate more heat than light.]

This is an issue for many distributions.  Solaris too is considering doing
something like that.  It's very sane and sensible to consider.

Presumably, the resulting stripped package will be named or identified in
such a way that it is clear that it's not the standard package, and it
will be easy for users to install the standard package once they have
everything else set up.  If so, I don't see any problems.

A former perl maintainer,

Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread David O'Brien

On Thu, May 02, 2002 at 01:17:40AM +0900, Dan Kogai wrote:
 Speaking of which, the whole build process does not use objective-C 
 (correct me if I am wrong).  

The cost of Objective-C, given we have to have C, is 1 minute in build
time, and 390K of diskspace (installed).  This is several orders of
manitude below Perl 5.6.x.


 So if you insist on stripping Perl it may 
 as well be unfair to leave GCC unstripped (I pretty much doubt GPL 
 allows you to do so, however).

Why in the world do you think the GPL prevents that?

-- 
-- David  ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



RE: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Fisher Mark
Title: RE: Save a few hunderd kilobytes or a few hundred perl users? 





 One possible solution might be as follow;
 
 rename /usr/src/contrib/perl5 to /usr/src/contrib/miniperl5
 
 and just add enough file to build miniperl.


I've read all the messages in this thread, but I'm still unclear -- are we talking about building the miniperl that Perl already creates during the build process? If not, the minimal perl for building the FreeBSD kernel should have a different name, like:

 smallperl
 modestperl
 tightperl
 midgetperl
 petiteperl
or something similar. I see much potential for confusion if miniperl means different Perl builds in different contexts.

===
Mark Leighton Fisher [EMAIL PROTECTED]
Thomson multimedia, Inc. Indianapolis IN
We have tamed lightning and used it to teach sand to think





Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Jarkko Hietaniemi

On Wed, May 01, 2002 at 03:00:45PM -0500, Fisher Mark wrote:
  One possible solution might be as follow;
  
  rename /usr/src/contrib/perl5 to /usr/src/contrib/miniperl5
  
  and just add enough file to build miniperl.
 
 I've read all the messages in this thread, but I'm still unclear -- are we
 talking about building the miniperl that Perl already creates during the
 build process?  If not, the minimal perl for building the FreeBSD kernel
 should have a different name, like:
   smallperl
   modestperl
   tightperl
   midgetperl
   petiteperl
 or something similar.  I see much potential for confusion if miniperl
 means different Perl builds in different contexts.

Yes, if it is anything more than the one single executable miniperl,
it should be called something else (it probably should have something
a little bit more, again, see Debian's perl-base for a reasonable set
of functionality).

I STRONGLY suggest that this discussion should get it's own mailing list,
though, this is off topic for both perl5-porters and freebsd-current.
I'm certain both those lists are busy enough, and OS distrib people
need a common ground.

[EMAIL PROTECTED]?  Ask, could you create the list?

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread M. Warner Losh

My take on this.  We should remove perl from the base, and
automatically install the port for most users in sysinstall, just like
we do with XFree86.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Kenneth Culver

But doesn't the kernel rely on perl for building?


perl5 ../../kern/vnode_if.pl -h ../../kern/vnode_if.src

does it make sense to remove it from the base when the base depends on it?

Ken

On Wed, 1 May 2002, M. Warner Losh wrote:

 My take on this.  We should remove perl from the base, and
 automatically install the port for most users in sysinstall, just like
 we do with XFree86.

 Warner

 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread M. Warner Losh

In message: [EMAIL PROTECTED]
Kenneth Culver [EMAIL PROTECTED] writes:
: But doesn't the kernel rely on perl for building?
: 
: 
: perl5 ../../kern/vnode_if.pl -h ../../kern/vnode_if.src
: 
: does it make sense to remove it from the base when the base depends on it?

The base will no longer depend on it before too much longer.  The
vnode and kobj dependencies are already gone in current.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Mark Murray

  and just add enough file to build miniperl.
 
 I've read all the messages in this thread, but I'm still unclear -- are we
 talking about building the miniperl that Perl already creates during the
 build process?  If not, the minimal perl for building the FreeBSD kernel
 should have a different name, like:
   smallperl
   modestperl
   tightperl
   midgetperl
   petiteperl

Sure, whatever. Smallperl it is. :-)

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-05-01 Thread Terry Lambert

Fisher Mark wrote:
 
Part 1.1Type: Plain Text (text/plain)

[ ... de-MIME-ed dso that it's distinguishable from an email virus ... ]

] I've read all the messages in this thread, but I'm still unclear -- are we
] talking about building the miniperl that Perl already creates during the
] build process?  If not, the minimal perl for building the FreeBSD kernel
] should have a different name, like:
] smallperl
] modestperl
] tightperl
] midgetperl
] petiteperl
] or something similar.  I see much potential for confusion if miniperl
] means different Perl builds in different contexts.


It's really assinine (IMO) to have a non-standard third party
application.

Either it's perl or it's not perl.

The big argument here appears to be that there are a number of
CPAN modules used for writing CGIs that FreeBSD doesn't include
by default, while the perl community itself seems intent on
bloating the base perl distribution with these things... and
most everyone else considers them security risks or bloat or
whatever.

Frankly, I think if anyone were honestly concerned about bloat,
we wouldn't have perl in the base system in the first place.

So let's just take the anti-bloat argument off the table.

That should clear the picture up considerably.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Jarkko Hietaniemi

(I promise that this is my last message about this matter to this large a
recipient list.  Who is the maintainer of the Perl package in FreeBSD?
Anton Berezin, I think? [EMAIL PROTECTED] CCed.)

Though I disagree with the tone of Dan Kogai, I must agree on the
technical grounds that leaving away standard modules and still calling
it Perl is not quite right.

I think both from the viewpoints of the Perl distribution *and* an OS
distribution *IF* modules have to be left out for space-saving reasons
the fair thing to do would be to make it clear to the users of the OS
distribution that what they are getting is not the full Perl.  This
will cut down the number of misunderstandings on both sides.

Firstly, both the outputs of perl -v and perl -V should be amended.
For example:

  $ perl -v

  This is perl, v5.6.1 built for i686-freebsd

  THIS INSTALLATION HAS BEEN MODIFIED FOR FREEBSD.  NOT ALL STANDARD
  MODULES ARE INCLUDED.  The missing modules are: ...
  To get the full standard installation, install ...

  Copyright 1987-2002, Larry Wall

  Perl may be copied only under the terms of either the Artistic License or the
  GNU General Public License, which may be found in the Perl 5 source kit.

  Complete documentation for Perl, including FAQ lists, should be found on
  this system using `man perl' or `perldoc perl'.  If you have access to the
  Internet, point your browser at http://www.perl.com/, the Perl Home Page.

Secondly, as the above message indicates, there should be a full Perl
installation available, using whatever packaging method is used by the
OS distribution.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Jarkko Hietaniemi

*Sigh*

Dan, I'm not entirely happy that you chose to take this discussion so
public, with such a wide CC list.  My experience is that these matters
are much better solved in smaller groups, where the signal/noise ratio
doesn't go straight to /dev/null.

[FWIW, I'm the release manager of the Perl 5.8.0-to-be]

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Maxim Sobolev

Jarkko Hietaniemi wrote:
 
 (I promise that this is my last message about this matter to this large a
 recipient list.  Who is the maintainer of the Perl package in FreeBSD?
 Anton Berezin, I think? [EMAIL PROTECTED] CCed.)
 
 Though I disagree with the tone of Dan Kogai, I must agree on the
 technical grounds that leaving away standard modules and still calling
 it Perl is not quite right.
 
 I think both from the viewpoints of the Perl distribution *and* an OS
 distribution *IF* modules have to be left out for space-saving reasons
 the fair thing to do would be to make it clear to the users of the OS
 distribution that what they are getting is not the full Perl.  This
 will cut down the number of misunderstandings on both sides.
 
 Firstly, both the outputs of perl -v and perl -V should be amended.
 For example:
 
   $ perl -v
 
   This is perl, v5.6.1 built for i686-freebsd
 
   THIS INSTALLATION HAS BEEN MODIFIED FOR FREEBSD.  NOT ALL STANDARD
   MODULES ARE INCLUDED.  The missing modules are: ...
   To get the full standard installation, install ...
 
   Copyright 1987-2002, Larry Wall
 
   Perl may be copied only under the terms of either the Artistic License or the
   GNU General Public License, which may be found in the Perl 5 source kit.
 
   Complete documentation for Perl, including FAQ lists, should be found on
   this system using `man perl' or `perldoc perl'.  If you have access to the
   Internet, point your browser at http://www.perl.com/, the Perl Home Page.
 
 Secondly, as the above message indicates, there should be a full Perl
 installation available, using whatever packaging method is used by the
 OS distribution.

Folks, please put the fscking modules back - the gain from their
removal isn't worth all fuzz and FUD that such removal generated.

Just UAH0.02 from bystander.

-Maxim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Mark Murray

 Mark, and FreeBSD committers,
 
I am deeply disappointed by the recent move to drop some of the files 
 (CGI.pm, et al.) in perl distribution /usr/src/contrib/perl5.  By saving 
 a few hundred kilobytes, you are risking losing a few hundred perl 
 hackers that run FreeBSD thereon.

OK...

 I hate to tell you this but I believe FreeBSD has already paid the price 
 for disregarding the community.  Are you--we (because I am part of the 
 FreeBSD community, at least for the time being) going to repeat the same 
 mistake?

Well, look at it this way. Perl is very hard to build already, and it
is very big, and you say it is getting bigger. All base freebsd needs
is the core language. The rest bloats the source tree, slows down builds
of the whole operating system and provides copious opportunities for
cross-builds and upgrades to fail.

Can we not come to a compromise here?

 Rafael Garcia-Suarez also wrote:
  Wait, vendors will soon have to struggle with the Borgified 5.8.0 
  release...
 
 Now please allow me to get a little personal.  I happened to maintain 
 Encode, the largest module in Perl 5.8.0 by far.  If you are to 
 castrate, this will definitely the first one to be.  The sad fact is 
 that I develop this very module on FreeBSD!

And it sounds like a perfect candidate for a FreeBSD port. The
bash(1) developer develops on FreeBSD (IIRC). That is a port. I have
no idea how many other of our 6000+ ports are developed on FreeBSD,
we dont have those in the base system unless they are needed for
the core operating system (such needs are things like, say,
OpenSSH, Kerberos5/Heimdal, Bind, Less, etc in src/contrib/).

 Since Encode is a part of Perl 5.8.0, I can't choose to license it so 
 that you can't castrate.  But that will disappoint me so much that I may 
 join those who kissed FreeBSD good-bye like many others who have chosen 
 to do so for the lack of regards.

You realise that you are asking for FreeBSD to bloat itself to
unusable levels by setting this precedent? How many _other_
modules are coming in? How big is Perl going to get? How much
longer is it going to take to build? What other software authors
will thus have valid reasons for having _their_ software as part
of the base system instead of as a port?

 P.S.  I would rather choose the NetBSD way of detaching Perl from core 
 distribution altogether.  That is far more politically correct.

There is merit to this point - make Perl5 a super-port (or
something), that is closer to the OS than a usual port but not part
of the base OS. I have no objection to this.

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Mark Murray

 (I promise that this is my last message about this matter to this large a
 recipient list.  Who is the maintainer of the Perl package in FreeBSD?
 Anton Berezin, I think? [EMAIL PROTECTED] CCed.)

Me - [EMAIL PROTECTED]

 Though I disagree with the tone of Dan Kogai, I must agree on the
 technical grounds that leaving away standard modules and still calling
 it Perl is not quite right.
 
 I think both from the viewpoints of the Perl distribution *and* an OS
 distribution *IF* modules have to be left out for space-saving reasons
 the fair thing to do would be to make it clear to the users of the OS
 distribution that what they are getting is not the full Perl.  This
 will cut down the number of misunderstandings on both sides.

Fair enough.

 Firstly, both the outputs of perl -v and perl -V should be amended.
 For example:
 
   $ perl -v
 
   This is perl, v5.6.1 built for i686-freebsd

... etc. I could do this.

 Secondly, as the above message indicates, there should be a full Perl
 installation available, using whatever packaging method is used by the
 OS distribution.

FreeBSD has the ports collection that has a full install of Perl 5.6.1.

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Jarkko Hietaniemi

 Me - [EMAIL PROTECTED]

Thanks.

  Firstly, both the outputs of perl -v and perl -V should be amended.
  For example:
  
$ perl -v
  
This is perl, v5.6.1 built for i686-freebsd
 
 ... etc. I could do this.

Sounds okay.

  Secondly, as the above message indicates, there should be a full Perl
  installation available, using whatever packaging method is used by the
  OS distribution.
 
 FreeBSD has the ports collection that has a full install of Perl 5.6.1.

Sounds even more okay.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Dan Kogai

First my apology for choices of stronger words than they have to.

On Wednesday, May 1, 2002, at 03:03 , Mark Murray wrote:
 Well, look at it this way. Perl is very hard to build already, and it
 is very big, and you say it is getting bigger. All base freebsd needs
 is the core language. The rest bloats the source tree, slows down builds
 of the whole operating system and provides copious opportunities for
 cross-builds and upgrades to fail.

One of the reasons I have chosen FreeBSD over Linuxen is its tidiness 
and slimness.  So I do understand your concerns.

 Can we not come to a compromise here?

One possible solution might be as follow;

rename /usr/src/contrib/perl5 to /usr/src/contrib/miniperl5

and just add enough file to build miniperl.  miniperl it may be it has 
all functionalities that should be required to 'make world' -- that is, 
of course, unless the build process uses external module.  I don't think 
anyone would object to that (AFAIK you need perl to build kernel).

 And it sounds like a perfect candidate for a FreeBSD port. The
 bash(1) developer develops on FreeBSD (IIRC). That is a port. I have
 no idea how many other of our 6000+ ports are developed on FreeBSD,
 we dont have those in the base system unless they are needed for
 the core operating system (such needs are things like, say,
 OpenSSH, Kerberos5/Heimdal, Bind, Less, etc in src/contrib/).

Yes,  I want p5-* cleaned up as well.  I just 'grep ^p5- 
/usr/ports/INDEX' and found 660!  That's way too many (or, at least two 
of which I have developed :).  Maybe we should BSDPANize all these.

I think if whole perl5 is distributed via ports only it wouldn've raised 
this much rants.  FreeBSD does need perl in core but not the whole thing 
and that is the problem.

But rule of the thumb is NOT TO REMOVE THE SOURCE.  /usr/src MAY BLOAT 
because it doesn't get installed by default (there are already bloated 
charmingly; 34853 files under /usr/src on FreeBSD 4.5-stable).  If you 
need size control do so via install process.   I would love to help in 
this area.  I think just a little tweak to hints file and you should be 
able to build a minimum perl just by passing right Configure directive.

 You realise that you are asking for FreeBSD to bloat itself to
 unusable levels by setting this precedent? How many _other_
 modules are coming in? How big is Perl going to get? How much
 longer is it going to take to build? What other software authors
 will thus have valid reasons for having _their_ software as part
 of the base system instead of as a port?

I don't mean to include those that don't come with perl-x.x.x.tar.gz.  
CGI.pm doesn't look like a necessity and it may even be true.  But the 
perl community voted to include it to perl standard distribution.

Besides, this 'pick, grok and trash or keep' process should be too 
time-consuming.  perl-current is already  3000 files big and it is 
already beyond a power of individual to look through every one of them.  
You need a better approach than handpick CGI.pm and others.


 P.S.  I would rather choose the NetBSD way of detaching Perl from core
 distribution altogether.  That is far more politically correct.

 There is merit to this point - make Perl5 a super-port (or
 something), that is closer to the OS than a usual port but not part
 of the base OS. I have no objection to this.

Maybe python and ruby should go for that approach as well and I see 
that's the way to go -- for ports.  We still need perl to build FreeBSD 
and we got to come up with a correct soultion -- not only politically 
but also technically.  Your current soultion is, to say the least yet 
with all due respect, incorrect in both criteria.

Dan the Proud Member of Both Communities


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Mark Murray

  Can we not come to a compromise here?
 
 One possible solution might be as follow;
 
 rename /usr/src/contrib/perl5 to /usr/src/contrib/miniperl5

Yes - in discussion the idea has already been brought up that all we
need of perl is miniperl. I'm going to experiment with world builds
that do this, and discuss it on our lists.

For what its worth, we have exactly the same problem with GCC - it
has 5 compilers in it already, and this is climbing. Our toolchain
maintainers are tearing their hair out over bloat and other issues
here.

 Yes,  I want p5-* cleaned up as well.  I just 'grep ^p5- 
 /usr/ports/INDEX' and found 660!  That's way too many (or, at least two 
 of which I have developed :).  Maybe we should BSDPANize all these.

I suspect that BSDPAN is used to some extent with all of these.

 I think if whole perl5 is distributed via ports only it wouldn've raised 
 this much rants.  FreeBSD does need perl in core but not the whole thing 
 and that is the problem.

100% agreement. I have even had a couple of folks asking for Perl 4
back! (No ways will I do that!)

 But rule of the thumb is NOT TO REMOVE THE SOURCE.  /usr/src MAY BLOAT 
 because it doesn't get installed by default (there are already bloated 
 charmingly; 34853 files under /usr/src on FreeBSD 4.5-stable).  If you 
 need size control do so via install process.   I would love to help in 
 this area.  I think just a little tweak to hints file and you should be 
 able to build a minimum perl just by passing right Configure directive.

I'm not sure that is acceptable. I believe that perl 5.8.0 will be
+- 45 MB. I cannot afford to import all of that - I'd get lynched.

  You realise that you are asking for FreeBSD to bloat itself to
  unusable levels by setting this precedent? How many _other_
  modules are coming in? How big is Perl going to get? How much
  longer is it going to take to build? What other software authors
  will thus have valid reasons for having _their_ software as part
  of the base system instead of as a port?
 
 I don't mean to include those that don't come with perl-x.x.x.tar.gz.  
 CGI.pm doesn't look like a necessity and it may even be true.  But the 
 perl community voted to include it to perl standard distribution.

If that becomes a license requirement, then FreeBSD may need to rethink
the need for perl in the base system. WY too much bloat for too
little gain.

 Besides, this 'pick, grok and trash or keep' process should be too 
 time-consuming.  perl-current is already  3000 files big and it is 
 already beyond a power of individual to look through every one of them.  
 You need a better approach than handpick CGI.pm and others.

Sure - but it is easy to blow away directories.

  P.S.  I would rather choose the NetBSD way of detaching Perl from core
  distribution altogether.  That is far more politically correct.
 
  There is merit to this point - make Perl5 a super-port (or
  something), that is closer to the OS than a usual port but not part
  of the base OS. I have no objection to this.
 
 Maybe python and ruby should go for that approach as well and I see 
 that's the way to go -- for ports.  We still need perl to build FreeBSD 
 and we got to come up with a correct soultion -- not only politically 
 but also technically.  Your current soultion is, to say the least yet 
 with all due respect, incorrect in both criteria.

We are working on removing the need for perl in building the kernel.
After that, it is just a case of rewiriting the userland utils that
need it (perhaps with miniperl).

 Dan the Proud Member of Both Communities

:-)

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Johnny Lam

On Wed, May 01, 2002 at 04:55:25AM +0900, Dan Kogai wrote:
 
 Maybe python and ruby should go for that approach as well and I see 
 that's the way to go -- for ports.  We still need perl to build FreeBSD 
 and we got to come up with a correct soultion -- not only politically 
 but also technically.  Your current soultion is, to say the least yet 
 with all due respect, incorrect in both criteria.

For the benefit of the FreeBSD users, I will reiterate a point I made on
a different thread:

I think Perl should be broken into two pieces: a miniperl distribution
that is called Perl and a separate Standard Perl Module Library
distribution.  They would be versioned separately so what's considered part
of the core Perl language isn't confused with what version of CGI.pm or
other random module is included with a Perl distribution.  It's clear that
the modules evolve much faster than Perl's release cycle, so the Perl
Library distribution could simply be on its release cycle.

NetBSD (I) used to separate out Perl into a separate miniperl package +
extensions, but I gave up on doing this because it was just getting to be
a maintainence headache -- with every Perl release, I had to wade through
a different module list to see what should be removed and what should stay
and I just got fed up with the extra work.  This is a lose for some of our
platforms that just don't have a lot of disk space to spare, e.g.
NetBSD/hpcmips.  With a Perl + Perl Library setup, we could more easily
control via a package system which modules are installed in a simpler,
more additive way.

Cheers,

-- Johnny Lam [EMAIL PROTECTED] [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Mark Murray

 I think Perl should be broken into two pieces: a miniperl distribution
 that is called Perl and a separate Standard Perl Module Library
 distribution.  They would be versioned separately so what's considered part
 of the core Perl language isn't confused with what version of CGI.pm or
 other random module is included with a Perl distribution.  It's clear that
 the modules evolve much faster than Perl's release cycle, so the Perl
 Library distribution could simply be on its release cycle.

I would be _delighted_ with this arrangement! *BSD could use the
Perl dist, and libraries would be excellent ports-fodder.

 NetBSD (I) used to separate out Perl into a separate miniperl package +
 extensions, but I gave up on doing this because it was just getting to be
 a maintainence headache -- with every Perl release, I had to wade through
 a different module list to see what should be removed and what should stay
 and I just got fed up with the extra work.  This is a lose for some of our
 platforms that just don't have a lot of disk space to spare, e.g.
 NetBSD/hpcmips.  With a Perl + Perl Library setup, we could more easily
 control via a package system which modules are installed in a simpler,
 more additive way.

A headache that would need to be addressed (IMO) is the one where
Perl makes too many decisions about runtime at compile time. This
makes things like cross building a real PITN.

If the above Perl was really minimalist, that would be good. If
it was basically some .c/.h (and .l/.y) files making the core
language + Dynaloader, with no need to execute _any_ perl during
the build, that would fit into the *BSD build paradigm very well
indeed, and that would probably support the Standard Perl Module
Library subsystem very well indeed, with no circular dependancies.

A _big_ headache is the config.sh script that is sometimes read by
a perl script, thus breaking any chance of putting shell variables
and expressions in there and having them expand properly.

Perl stuff like perldoc, pod2man we would like to be able to build
with sed/awk scripts if necessary.

I fully recognise as a programmer that this is not trivial work :-).

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Mark Murray

  Perl stuff like perldoc, pod2man we would like to be able to build
  with sed/awk scripts if necessary.
 
 All the perl developers that I know like writing perl.

I wonder why that is? ;-)

 Given the choice of writing something in sed sed/awk versus writing something
 in perl, which do you think they'd prefer? :-)

No brainer! :-)

 In fact, I don't know any awk, and I hardly know any sed.
 Then again, I seem to spend more of my time writing perl in C than in perl.
 
 I don't understand the *BSD build paradigm, so I've no idea if I'm making
 rash assumptions here, but perl's building paradigm (as I understand it) is
 to build a minimal perl (miniperl) and then write the later stages of the
 build in perl.

BSD's build paradigm is to do it all in makefiles, using make's
dependancy rules.

 Having done a port to a non Unix system without a shell, it irritates
 me that there *are* shell scripts used at all after miniperl is
 built. For portability reasons it would be nicer if everything after
 miniperl was written in 100% perl, as it's usually possible to
 bootstrap a good-enough miniperl from a hand-edited config.h file. But
 this is a digression.

Hand crafted config.h files are a pain if you need to do some configs
(word size, endianness, build vs. run architecture, etc). If you
use system headers for this, then you are laughing.

If building scripts (say, perldoc) is as simple as running a script
through (only) miniperl, that would be OK - miniperl could be a
part of the OS build toolchain. I had something in mind like %%FOO%%
strings that would be simple to sed(1) into their real values at
build time.

I am under no illusions that doing this is major work for you guys.

 Would I be right in guessing that the pain to *BSD in the perl build system
 is that even if there is an existing /usr/bin/perl, we perl porters insist
 on writing all our perl building scripts using perl features only found in
 the perl we're bootstrapping. Hence it's not possible to use the probably
 older /usr/bin/perl to finish making perl, and so *BSD has to use the
 uninstalled new perl in /usr/obj. Which causes problems bootstrapping new
 binary formats (eg existing kernel only runs a.out binaries, new kernel runs
 a.out and ELF, new userspace is being built as ELF, but how does one run the
 uninstalled ELF perl during make world?) At least, this was the stage where
 I had fun when upgrading my FreeBSD box from 4.0 to 4.5.

That is a big part of it. Another big part of the the problem is that
build time requirements become run-time defaults, like where you put
stuff for the build vs. where stuff is eventually put stuff at install
time. This is particularly bad when trying to cross build, as perl
decides at build time what CPU it is going to _run_ on, and fouls
up :-). We've mostly fixed that, but it is very fragile, and I'm
dreading the next perl upgrade.

*BSD can fix most of this using the right headers (eg: sys/endian.h)
and the right integer types (u_int32_t, int64_t, etc). We've dethreaded
lots of the build, and we build libperl.(so|a) mostly with straight
makefiles. We can build perl, suidperl and miniperl with just a little
bit of scripting magic (mostly for Dynaloader), but the dependancy
list is very big (MakeMaker etc).

 (This may sound corny or obsequious, but people rarely seem to say thank you,
 and assume it's taken for granted. My FreeBSD box works very well. Thank you
 for FreeBSD. Please keep up the good work.)

Thank you for Perl! We gripe about its build, but it is a very useful
tool. Thank _you_!

And a very hearty Thank You for this opportunity to discuss this
thorny issue with you!

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Christopher Vance

On Tue, Apr 30, 2002 at 10:29:00PM +0100, Mark Murray wrote:
:  NetBSD (I) used to separate out Perl into a separate miniperl package +
:  extensions, but I gave up on doing this because it was just getting to be
:  a maintainence headache -- with every Perl release, I had to wade through
:  a different module list to see what should be removed and what should stay
:  and I just got fed up with the extra work.  This is a lose for some of our
:  platforms that just don't have a lot of disk space to spare, e.g.
:  NetBSD/hpcmips.  With a Perl + Perl Library setup, we could more easily
:  control via a package system which modules are installed in a simpler,
:  more additive way.

NetBSD (-current, at least) does not have perl in the base.  OpenBSD
has 5.6.something.

Perhaps FreeBSD could benefit from following NetBSD, and use awk or
whatever to replace the perl stuff for kernel build and wherever else.

People who actually want perl could then install a miniperl package
and as many modules as they need or like, up to and including the very
latest full-bloat^H^Hwn version, if desired.

I used to write lots of (relatively simple) perl, mostly without using
many of the presupplied modules, but now I tend towards Python for
many (but not all) of those tasks.

-- 
Christopher Vance

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Save a few hunderd kilobytes or a few hundred perl users?

2002-04-30 Thread Hugo van der Sanden

Mark Murray [EMAIL PROTECTED] wrote:
: I think Perl should be broken into two pieces: a miniperl distribution
: that is called Perl and a separate Standard Perl Module Library
: distribution.  They would be versioned separately so what's considered part
: of the core Perl language isn't confused with what version of CGI.pm or
: other random module is included with a Perl distribution.  It's clear that
: the modules evolve much faster than Perl's release cycle, so the Perl
: Library distribution could simply be on its release cycle.
:
:I would be _delighted_ with this arrangement! *BSD could use the
:Perl dist, and libraries would be excellent ports-fodder.

This was an issue raised at the perl5-porters meeting during the
conference in San Diego last year. I don't remember the details
precisely - I'm trying to track them down - but as far as I can
recall some consensus was reached that it should in principle be
possible to find a way to offer particular subsets or supersets
of the standard perl installation.

There are some problems to be overcome, not least the social ones
(my ISP won't install CPAN packages), but it may be possible to
overcome some of them by providing installations targeted at
particular domains - 'perl for booting', 'perl for ISPs' etc -
with the same imprimatur as Perl itself. I hope to see some
progress made on this in the 5.10 cycle.

Hugo

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message