Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Here are links to the recent (and heated) threads on p5p about this :

    FreeBSD castrates Perl ? [] and Save a few hundred kilobytes or a few hundred perl users? []

    The FreeBSD folks did want to cut down (à la Debian), and now remove, Perl from the core because of the "libraries bloat"; currently Perl is used by the FreeBSD core and built during the build process of FreeBSD itself (if I understand correctly). Obviously they don't need all the core modules for this task.

    IIRC Jarkko requested that a new mailing list, perl-dist, be created, for dealing with OS distribution issues. That's a good idea. What's the status on this?

    • IIRC Jarkko requested that a new mailing list, perl-dist, be created, for dealing with OS distribution issues. That's a good idea. What's the status on this?

      The list is up, running and archived at []

      After a brief flurry of messages it's gone rather quiet.

      My summary of the discusion so far was that the debate arose because the perl community regard "perl version foo" as meaning everything you find in the tarball for that version - ie interpreter and libraries, whereas the FreeBSD community regarded it as meaning the interpreter - libraries are a useful benefit that happened to be there.

      I tried to summarize the two positions in this message []:

      perl5-porters: When we say perl version X, we mean both the interpreter and all the libraries that were released in the source package for X. Many scripts make assumptions about which modules are present based on the version of the interpreter they are running under, and p5p considers this supported behaviour. Hence we don't want scripts (or users) to encounter something they think is perl version X which doesn't have all the libraries, and doesn't say that it doesn't fulfil this expectation of all the libraries

      FreeBSD: We'd like to have the perl intepreter available to remake the FreeBSD userspace and kernel, but the full libraries that come with it are far too big a burden for the core. We'd like to provide the rest of perl as a package, so that those want to rebuild the kernel but don't want to run perl themselves aren't forced to have perl present. to which Mark Murray (the FreeBSD perl guy) added Plus we'd like the perl interpreter to be in a standard place so that those perverts who write module-free scripts are able to do so. ;-) Also, in terms of the "perl contract", its nice to have perl in /usr/bin/perl.

      My suggestion was that these views are compatible if FreeBSD describes what it ships in core as a "derived work", telling people that they are not getting the full perl. (and how to install it). Mark Murray was happy with this idea, and was going to consult the FreeBSD core team about it. An advantage was that this would actually mean that they could reduce further the amount of bulk in their core tree, which increases the chance of perl remaining their tool of choice in kernel building.

      Please remember that the FreeBSD folks are trying to minimise the size of the absolute-must-have files for building the OS and base userspace. Their view, correct in my opinion, is that it is unweildy to mandate people to download a large amount of stuff superfluous to the kernel build process if you want to rebuild your kernel. This is not the default OS install we're talking about here, it's the kernel. They also want to be able to cross-compile the kernel, which means cross compiling all the tools, and perl really doesn't cross compile cleanly. perl is just a tool for getting their job done, and if failing to resolve issues mean that it's easier for them to re-write parts of their kernel build system in sed and awk, they will.

      Finally, note that it's the size 5.6 that they are concerned about. It's best that we resolve this now, before they see the handiwork of Jarkko-of-Borg.

      • This mailing list really needs to be listed at [].

        FWIW (I'm not a FreeBSD user), keeping Perl separate from the core OS looks like a good thing. It makes Perl easier to upgrade or to recompile, without inflicting damage to your OS or to its package-management system. Redhat's Perl RPM has too much dependencies with other core RPMs to make it easy to replace -- so I always end up with recompiling my own perls in alternate places. The situation is similar on Debian and on Solaris.

        About cut-down d

        • I'm not psychic so I can't always catch the new lists and I rely on people to submit new lists via the form on the, feel free to submit it :)

      • Follow-up own message. Most bad style :-(

        Mark Murray was happy with this idea, and was going to consult the FreeBSD core team about it.

        Aha. Now I read the other links, and actually realise the relative times on them. He has done his consultation, and the summary message back to the perl-dist would appear to be delayed somewhere.

      • They could go the way of Sun/Solaris/Alan Burlison with a mini-perl that has minimal but useful functionality in the bootable mini-root.

        Finally, note that it's the size 5.6 that they are concerned about. It's best that we resolve this now, before they see the handiwork of Jarkko-of-Borg.

        While I realise that the job of pumpkin is the absolutely most thankless and most unpleasant job in this little community I bristle whenever I hear either the people who bitch about bloat or the people who bitch about t

        • Oops. Sorry. Forgot the smiley after "Jarkko-of-Borg". D'oh.

          It wasn't a bitch (although I agree that foolishly I wrote something indistinguishable from one). I think that the first reference to Borg and assimilation is here on p5p []. It was meant as a joke (possible it's too much of an in joke). Jarrko's referred to himself as Borg here [],here (when assimilating the Netware port and Memoize) [], here [], here [] and a few other places too.

          I probably assumed too much, and left too much unsaid. By now, many people wil

          • :) I still want to make the t-shirts for P5P et. al that have embroidered "Thanks," on the front and "Applied!" on the back.

            The pumpkin model works pretty well except that it is an awful job that few can do both in skill and in patience so the candidate pool is very small to begin with...I'm skeptical that a committee will do any better since critics of the 5.x product don't keep the 'good of the many vs. what i want' in mind so...I doubt that will change as it will need to in order to make a valuable im

    • The FreeBSD folks did want to cut down (à la Debian)

      woa there... in Debian there are two packages, perl-base and perl-modules. perl-base's description says:

      This is a stripped down Perl with only essential libraries. To make full use of Perl, you'll want to install the `perl', `perl-modules' and optionally `perl-doc' packages which supplement this one.

      perl-base is used by the base system and is an essential package, this means, you have to really really really want to deinstall it to remove perl

      • That's more or less what I meant... The core libraries and docs are not part of Debian's perl-base package. And Debian's system relies only on perl-base (right?)

        One could argue for ages whether the Perl distribution is too large. In fact, it's not targeted to people that release OSes. It's targeted to people that want to install a programming language on their computer, with a good set of proof-tested modules. So Debian's packaging makes sense : the perl-base package is to be used by the system, and the oth

        • And Debian's system relies only on perl-base (right?)

          Yes, the base build system only depends on perl-base. If a package depends only on perl-base, then it doesn't have to list any dependencies since packages can assume something listed as essential will always be there.

          (From the previous Perl maintainer that actually made this split.)
    • There was also a Thread [] on this over at Perlmonks a few days back.

  • Finally (Score:2, Interesting)

    While I won't claim to follow the thread in detail, I think this is a blessing in disguise.

    The only real complaint I had when using FBSD was that the perl in the base system was still 5.0x, and more and more modules are wanting 5.6.x.

    Installing perl for the ports collection and having two perl installs always seemed like accidents waiting to happen from time to time, esp if you forget to switch perl interps before a ports module install or a buildworld.

    Just my $0.0000002 worth.

    • i have been building FreeBSD without perl since 5.6.0 came out, i havent had any problems at all.

      it sounds like a good idea to have perl outside the base system.
      now we just need smarter perl module checking in the ports tree :)

      ps. i have been trying to work out how to improve the perl module checking in the ports tree but i got stuck (i havent sent it to the FreeBSD ports team yet as it doesnt work yet)
      Do not try the patience of Wizards, for they are subtle and quick to anger.
    • I prefer to compile everything that I can compile that use the ports, the main reason that I have not been connected til now, usually I get the tar balls from mags, the fact this is the way that I can have programs like GIMP or ImageMagick with PerlMagick in FreeBSD. I use to test first all and then erase the original binaries or directories of the distribution, in this case Perl base from 'free', if you have a CD with the distribution you can return to the origins if you want. To me is is a solution and w
  • According to a comment by Patrick Gerardella over at's story on this, perl will still be installed by default, but not as part of the core system.

    For those not entrenched with BSD's ports/sys system, what this means is that in the past, with perl as part of CORE, every time you upgraded the system by the BSD standard 'make build' or 'make world' (depending on BSD flavor) you ended up compiling perl again from scratch, greatly adding to the complexity of the process.

    What it also mean

    • What it also meant was that keeping your own perl on the box was problematic at best, damn near impossible at worst. If you compiled your own perl with, say, threads or shlibperl, the next system update could blow it away.

      <rant direction="omnidirectional">

      This is such a pervasive myth, it's almost an urban legend. It's been repeated so often that it's easier to just assume it's true.

      First of all, the stock Perl in FreeBSD 4.x (and maybe even the late 3.x line; my memory is spotty) is Perl 5.

      • I agree. Really.

        Haste and distractions (I was on a conference call at the time) caused me to overstate the complexity of maintaining two perls. During the course of my job I'm used to describing technical terms to non technical people. I forgot my target audience and did that here.

        I have maintained two perls. For a brief time I even maintained three on a Solaris box. (5.005_03, 5.6.0 with threads, 5.6.0 without threads).

        That said, easy or hard, it's not exactly the most optimal way to do it. I used to

  • []

    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


    Ilya Martynov ( [])