Re: Save a few hunderd kilobytes or a few hundred perl users
> 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?
> 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?
> >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?
>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?
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?
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?
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?
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: New Perl list (was: Save a few hunderd kilobytes or a few hundred perl users?)
On Wed, May 01, 2002 at 02:37:10PM -0700, Ask Bjoern Hansen wrote: > On Wed, 1 May 2002, Jarkko Hietaniemi wrote: > > > 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? > > [EMAIL PROTECTED] will accept your subscription request. > Within a few hours of the first posting to the list it will also be > available at news://nntp.perl.org/perl.dist > > > Elaine, please get the list description and stuff from Jarkko and > put the list on lists.perl.org. :) The charter of the [EMAIL PROTECTED] mailing list is to discuss the "splitting" or "repackaging" of the Perl distribution. The new forum has been created, I hope the clamour about this subject in p5p and freebsd-current will now cease. -- $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?
> > 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?
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?
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?
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?
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?
> 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 " where != 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?
> 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?
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?
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?
> > 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?
[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?
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?
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?
> 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?
> NetBSD (-current, at least) does not have perl in the base. OpenBSD > has 5.6.. *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?
On Wed, May 01, 2002 at 04:22:44AM +0100, Hugo van der Sanden wrote:
>
> 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.
The "my ISP won't install CPAN packages" problem would be solved by my
proposal of having separate perl-5.10.0 and perl-library-1.0
distributions because *both* would be recommended to be installed by
the Perl community, and the world-at-large would learn that they
really need to install both to match the functionality of previous
releases of perl. My proposal also makes it easy to create the
targetted Perl installations that you're suggesting:
perl-5.10.0
perl-library-standard-1.0
perl-library-ISP-1.0
perl-library-bioinformatics-1.0
perl-library-sysadmin-1.0
...
A user would install perl-5.10.0 then choose the Perl module library
most relevant to his/her domain of interest. They could each have
individual release cycles, and the responsibility for the domain-
specific Perl libraries could be delegated to the groups that have the
most experience within those domains.
Cheers,
-- Johnny Lam <[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?
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
Re: Save a few hunderd kilobytes or a few hundred perl users?
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.. 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?
> > 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?
> 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?
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?
> > 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?
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?
> 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?
> (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?
> 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?
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?
*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?
(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
Save a few hunderd kilobytes or a few hundred perl users?
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. On Tuesday, April 30, 2002, at 11:06 , Mark Murray wrote: >> BTW, I develop perl scripts using CGI on systems that don't have >> apache, or any web server installed. It's not a requisite of cgi.pm, >> and it allows users to enter variable/value pairs on stdin when not >> running inside of a CGI environment. > > What is wrong with installing the CGI.pm port (which is usually more > up-to-date that the one bundled with perl)? Definitely nothing wrong for FreeBSD the Operating System and Perl the Programming Language. Nevertheless, that is dead wrong for Perl the Community and FreeBSD the Community in turn. To prove my point, let me quote the few from Perl5 porters. On Tuesday, April 30, 2002, at 09:50 , Christopher Masto wrote: > Seeing this happen makes me sad. It seems to go against the spirit of > the Artistic license. People who use "Perl" that comes with FreeBSD > won't be getting the standard Perl package. On Tuesday, April 30, 2002, at 10:25 , Chris Nandor wrote: > *ALL* of those files are in perl-5.6.1. Sys::Hostname and Sys::Syslog > certainly are; they are in ext/, however, and copied to lib/ when being > built. The others are a part of the CGI package. Please inform him > that he is incorrect. And please make sure that it is documented that > perl in FreeBSD is *not* the standard perl and is missing some key > pieces. :/ Of course, FreeBSD is not the only OS that chose to castrate Perl. On Tuesday, April 30, 2002, at 11:32 , Rafael Garcia-Suarez wrote: > Other vendors (debian...) also cut down the perl-5.6.1 package > to something more basic. I think that's OK to distribute CGI separately, > as it can be found on CPAN (as long as it's properly documented). > However, > cutting off packages that have no dual life on CPAN is more > questionable. I think castration is allowed when you MUST and when you CAN; Perl's Artistic License definitely allows you to castrate (and even mutilate if you will!). But that does not mean perl wants to be castrated at all. Like FreeBSD, perl is developed and maintained by a large team of individuals. Perl is not just a programming language as FreeBSD is not just an Operating System. By dropping CGI.pm or others that is harmless for base functionality does hurt the community. 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? 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! 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. Because, I, for one, rather choose to be a part of a community than a programmer if I have to choose. Dan the *BSD advocate AND Perl5 Porter -- _ Dan Kogai __/ CEO, DAN co. ltd. /__ /-+-/ 2-8-14-418 Shiomi Koto-ku Tokyo 135-0052 Japan /--/--- mailto: [EMAIL PROTECTED] / http://www.dan.co.jp/ - __/ /Tel:+81 3-5665-6131 Fax:+81 3-5665-6132 GPG Key: http://www.dan.co.jp/~dankogai/dankogai.gpg.asc P.S. I would rather choose the NetBSD way of detaching Perl from core distribution altogether. That is far more politically correct. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
