Slashdot Mirror
FreeBSD: Perl to be removed
zmcgrew writes "From Daemon News:
"The decision was made to remove Perl from the FreeBSD -current base system [earlier story ]. Perl will be supported as a port that the user can install after the base installation, however it will no longer be required. Mark Murray put out a call to the -current mailing list asking for volunteers to port all Perl scripts in the base system to another language, such as sh or C. All critical programs are already being ported, with only a few minor ones left to be claimed." Wow..."
"The decision was made to remove Perl from the FreeBSD -current base system [earlier story ]. Perl will be supported as a port that the user can install after the base installation, however it will no longer be required. Mark Murray put out a call to the -current mailing list asking for volunteers to port all Perl scripts in the base system to another language, such as sh or C. All critical programs are already being ported, with only a few minor ones left to be claimed." Wow..."
Perl's not a base requirement in most Linux distributions or other commercial Unix implementations. I would say it's a smart move for the FreeBSD team.
It appears that having Perl in the base distro has the following problems:
1. It increases the distro image size.
2. It forces everyone to use the same version of Perl.
3. If someone tries to install over that version or just even patch it, it can break stuff in BSD which needed the old version.
4. Installing multiple copies imposes weird symlink tricks or else breaks other stuff.
Like it or not from a perl perspective, perl shouldn't be required to install the OS any more than X11, tcl, python etc should be. *nix has gotten too fat. Praised be FreeBSD for getting back to its roots! Now I can install a sane perl without having to rip the old one out by its hair.
Ever install HatRed? 240 packages later, you have a 'stripped down' *nix. Talk about losing sight of the original idea....
I can't remember if I had to install perl for NetBSD, I thought I did, but it may be just the added packages. I know on one NetBSD box I have it has perl installed as a package. I think FreeBSD is doing the right thing. I mean it is not that hard to do 'make install' in the ports to install perl.
Only 'flamers' flame!
It's easier to keep perl up to date and apply patches for it (maintain) if there are no critical system pieces that depend on it. Perl was never considered 'standard' and shouldn't be installed on systems that don't need or use it. Of course many people who live/breathe/eat perl are going to be surprised, but this is good for them.
-Adam
This has been discussed on Permonks
You can also read the discussion that led to this here
tstock
Not only is it more up-to-date, more easily upgraded, and able to get as bloated as Perl demands, it also includes the excellent BSDPAN.
/usr/pkg, makes them LOCALBASE clean, \o/
BSDPAN allows you to install CPAN modules and manage them like any other package (pkg_info, pkg_delete, etc), and for weenies like me who set LOCALBASE to
/usr/ports/lang/perl5 is not just there for completeness. Even if you have Perl installed from base, chances are anyone even remotely interested in Perl will want to replace it with the port anyway.
Now, if only we can convince core to remove sendmail...
This is great! First thing I do with my nice FreeBSD installs is remake world with NO_BIND, NO_SENDMAIL and NO_PERL. The other thing I'd like is separate packaging of all ports in their own directories in, say, /app.
/app/perl (ie. current) to /app/perl-x.y.z
That way you can have more than one version installed, and symlink
I'd like to see *all* parts of FreeBSD (incl. kernel, etc.) represented as pseudo-ports/packages in the package database to ease componentized installation (eg. no 'gcc' for client machines) and simple networked FS management.
I use things like Perl all the time, but I'd like the control of which Perl, which GCC, etc.
I couldn't stand the obsolete perl 5.005 which was on the base system... once you install 5.6.1, things can mess up pretty quickly if you don't take care to separate things... not to say that you have to convince sysadmins...
... one day...
The worse is that the perl5 base would install obsolete modules, like cgi.pm.... and now if you install the cgi perl port, you have to either remove the original cgi.pm (will break at the next make installword) or tweak PERL5LIB to insert the path to the new modules before the others.... thanks god all that pain in the . will be gone
Now all my old scripts will break. It wasn't until about a year ago that I started using "#!/usr/bin/env perl" instead of "#!/usr/bin/perl". Are they expecting me to symlink, or what?
Sorry.. didn't make it clear. I put *all* major applications/packages where I track multiple versions (eg. Apache, Perl, Sendmail/Postfix, MySQL, PHP, prc-tools, GD, etc., etc.) in /app, allowing me to build and test newer versions without overwriting the current "approved" version.
/app in a different way, I avoid /usr/local for packages that I track. Throwaway, uncustomised packages (eg. zip, word2x) which I'm unlikely to ever get round to upgrading just go in /usr/local as usual.
/opt on other Unices, but since there doesn't seem to be a consensus on the correct structure of /opt, I avoid that name to prevent confusion when new sysadmins come on board.
Because I manage
/app/pkg (package installs)
/app/src (source)
/app/etc (package configs)
/app/var (logs, etc)
I tend to also keep the configure parameters and also config files in CVS.
Sounds like a lot of work, but worth it. The number of production boxes I've used (that others have set up) where different versions of things are spread around everywhere has made me reasonably tidy and regimented when setting up a production box.
I guess it's like
The only idiotic thing here is your argument.
I'm a Tivoli administrator and run into all sorts of issues because of Tivoli's continued support of perl v4. Perl 4 doesn't support useful features like modules, and the syntax is signifigantly different in a number of areas. But because so many customers invested a fortune in man-hours and consulting time to develop Tivoli scripts and perl-based policies, everyone is going to be stuck with a very old version of perl for the indefinate future.
Perl 5 is going to be a dinosaur just like perl 4 is today. When Perl 7 is out and there's a problem with a server that is a pain in the ass to fix becuase nobody remembers Perl 5 syntax, you'll be in the same boat.
ksh and sh are standardized on all platforms and do a good job. Use them whenever you can.
Conformity is the jailer of freedom and enemy of growth. -JFK
In the real world, most sysadmin labor hours are spent on servers and workstations running powerful, modern hardware. And what they need are transparent, diagnosable systems. When things go wrong, or when they have a complex task to accomplish on a short schedule, they need to be able to reach inside the system and extend it. Hard coding system logic into C programs is extremely counterproductive, and sh is so limited and restrictive that you have to jump through all sorts of ridiculous hoops to accomplish the simplest tasks. What is needed is a good, full-featured scripting language that the average sysadmin can master quickly. If I was paying to have my dream OS written, it would be Python, but Perl is good enough.
-- ;-)
Kuro5hin.org: where the good times never end.
But they haven't! They are ramming C and sh down the average sysadmin's throat, without the slightest thought about what is appropriate for that sysadmin.
Don't be an ass. What they are doing is making sure that a default install of FreeBSD doesn't require a particular version of perl to be installed.
Great. You can go and add the one you want afterwards.
What is needed is a good, full-featured scripting language that the average sysadmin can master quickly. If I was paying to have my dream OS written, it would be Python, but Perl is good enough.
This is exactly what FreeBSD offers you. After you've installed it. Go add Python. You don't need to worry that the system relies on a particular version of Python, so you can install the one you want. In contrast to RedHat Linux which is wedded inseperably to Python 1.5.2, which has been out of data for about a millennia.
Hint: Perl has always been hard to incorporate into the BSD build structure and breaks easily, especially in cases like cross-compilation. Because it's so fragile, it's a lot of work to maintain and tends to fall out of date. These are the kinds of things you need to worry about when you're actually maintaining an operating system, instead of throwing a kernel and 100's of externally maintained packages together and calling it done.
[mailto:owner
Sent: Wednesday, May 15, 2002 9:44 AM
To: announce@freebsd.org
Subject: Perl5 is leaving the base system for 5.0 and after!
Hello folks!
It has been decided after some debate to remove Perl5 from the "Base FreeBSD" sources. This decision was not taken lightly, and was taken in consultation with (but not seeking the approval of) the perl5 developer community.
There are 2 main reasons for this:
1) Perl5 is getting larger very fast, and FreeBSD cannot afford the time and space to build and maintain it.
2) Upgrading the "base perl" is a nightmare that regularly breaks upgrades and cross-builds, to the intense annoyance of the FreeBSD developer community.
Speaking as the "Perl5 guy", keeping FreeBSD's "base perl" up to date was hellish, and folks who wish a return to that state should please consider doing this work in my place. BEWARE! This job is not trivial!
PERL IS NOT BEING OSTRACISED! FreeBSD is not taking this action because of any dispute between the FreeBSD community and the Perl community - such a dispute DOES NOT EXIST! In fact, the Perl community have been exemplary in their attempts to understand the problem, and in their proposals to deal with it. FreeBSD DOES NOT HATE PERL!
Some time in the future, perl may be split in half, such that the core language and the standard libraries may be separately installed. In such a case, FreeBSD might be in a position to better deal with the problem of the very large perl libraries. Such splitting will be done by the perl community, NOT by us, although we will be taking note.
In the meanwhile, the Perl5 Port will continue to be available, and continued discussion indicates that there is very substantial support for it to be installed by default (or near-default) by sysinstall.
This will result in a FreeBSD that has effectively the same Perl5 that is kept up-to-date in ports, rather than the one that is left to rot in STABLE.
This update will _NOT_ be MFCed. The first FreeBSD that has no perl in the default sources will be 5.0-RELEASE, when that is released at the end of this year. FreeBSD-4.n will continue with the perl that it currently has.
The ports system will continue to support Perl5.
M .sig is umop ap!sdn
--
o Mark Murray
\_
O.\_ Warning: this
This is the moderated mailing list freebsd-announce.
The list contains announcements of new FreeBSD capabilities,
important events and project milestones.
See also the FreeBSD Web pages at http://www.freebsd.org