use Perl Log In
Perl to be removed from FreeBSD base
koschei was first to write: "As noted on some other sites, Perl is being removed from the FreeBSD base system. It will still be available as part of the ports system, you just won't be able to assume the system has Perl. One can only assume they will also be reducing everything else in the base to programs that need small run-time systems." A major Unix shipping without Perl? I hear not even Solaris does that these days...
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.

Relevant p5p threads (Score:3, Interesting)
FreeBSD castrates Perl ? [mpe.mpg.de] and Save a few hundred kilobytes or a few hundred perl users? [mpe.mpg.de]
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?
Reply to This
Re:Relevant p5p threads (Score:5, Informative)
The list is up, running and archived at http://archive.develooper.com/perl-dist@perl.org/ [develooper.com]
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 [develooper.com]:
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
sedandawk, 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.
Reply to This
Parent
Re:Relevant p5p threads (Score:1)
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
Re:Relevant p5p threads (Score:2)
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 lists.cpan.org site...so, feel free to submit it :)
Re:Relevant p5p threads (Score:1)
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.
Re:Relevant p5p threads (Score:2)
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
Re:Relevant p5p threads (Score:1)
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 [mpe.mpg.de]. It was meant as a joke (possible it's too much of an in joke). Jarrko's referred to himself as Borg here [mpe.mpg.de],here (when assimilating the Netware port and Memoize) [mpe.mpg.de], here [mpe.mpg.de], here [mpe.mpg.de] and a few other places too.
I probably assumed too much, and left too much unsaid. By now, many people wil
Re:Relevant p5p threads (Score:2)
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
Re:Relevant p5p threads (Score:2, Informative)
woa there... in Debian there are two packages, perl-base and perl-modules. perl-base's description says:
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
Re:Relevant p5p threads (Score:1)
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
Re:Relevant p5p threads (Score:1)
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.)
Re:Relevant p5p threads (Score:1)
There was also a Thread [perlmonks.org] 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.
Re:Finally (Score:1)
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.
Re:Finally (Score:1)
It's not GONE, just delayered. (Score:2, Informative)
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
Re:It's not GONE, just delayered. (Score:3, Informative)
<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.
Re:It's not GONE, just delayered. (Score:1)
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
Mark Murray's post to freebsd-announce maillist. (Score:2, Interesting)
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 (http://martynov.org/ [martynov.org])