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