Slashdot Mirror

← Back to Stories (view on slashdot.org)

FreeBSD: Perl to be removed

Posted by Hemos on from the killing-the-perl dept.

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..."

4 of 97 comments (clear)

  1. Re:The obvious question remains by hawkstone · · Score: 5, Informative

    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.

  2. perlmonks by tstock · · Score: 4, Informative

    This has been discussed on Permonks

    You can also read the discussion that led to this here

    tstock

  3. Re:interesting by Gid1 · · Score: 4, Informative

    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.

    That way you can have more than one version installed, and symlink /app/perl (ie. current) to /app/perl-x.y.z

    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.

  4. Re:/app? by Gid1 · · Score: 4, Informative

    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.

    Because I manage /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.

    /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 /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.