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...
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?
Re:Relevant p5p threads
nicholas on 2002-05-14T10:19:50
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 http://archive.develooper.com/perl-dist@perl.org/
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
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.
Re:Relevant p5p threads
rafael on 2002-05-14T10:46:39
This mailing list really needs to be listed at lists.perl.org.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 distributions of Perl: indeed these need to be flagged as "derived work". The perl-dist mailing list is there to help people about that. Removing modules and utilities from the official Perl distribution, and distributing them in separate packages, is not a trivial task.
Re:Relevant p5p threads
hfb on 2002-05-14T18:46:39
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
nicholas on 2002-05-14T11:01:30
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.
Re:Relevant p5p threads
hfb on 2002-05-14T18:56:21
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 their modules not making it into the core. I don't want to start a big row here over said issue rather just point out he's screwed either way and that one could simply appreciate the decisions that went into adding or not adding them.
Re:Relevant p5p threads
nicholas on 2002-05-15T12:16:58
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 will know that perl 5.8 tarball will be a lot bigger than 5.6, because there are many more modules in it. Hence there might be some confusion, with people thinking that the FreeBSD folks were worried about 5.8.
I agree Jarkko can't win on what mature and useful modules should be provided as core, when everyone has conficting ideas on what's useful and what's mature. With 5.8 RC1 soon, it seems that the biggest new size increaser by far in 5.8 will be the Encode tree, to provide Unicode <> Native character set translations. And this is all new, rather than an established module newly assimilated from CPAN.
I think the fact that the pumpkin is in a lose-lose situation is why we need to move away from the current one-size-fits-all model. Jarkko's done (and is still doing) an excellent job, and I can't see how he could do have done it any better.
Re:Relevant p5p threads
hfb on 2002-05-15T15:48:45
:) 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 improvement in the situation instead of going backwards.
Re:Relevant p5p threads
m2 on 2002-05-14T13:49:08
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 from the system. perl-modules is "standard". This means, most Debian installations will have it by default. You can remove it but you probably have it. For packages, this means they have to declare a depencency on it if they want to use any of the modules that package provides.
Moreover, there's a perl package. If you install that, you get current Perl (5.6.1 as I write), and you get a pointer to the perl-doc package.
Yes, the default Perl distribution contains too much stuff, but Debian makes it easy for the users to get the default (and full) Perl distribution.
Re:Relevant p5p threads
rafael on 2002-05-14T14:42:37
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 other packages are useful to people that want to write and to use Perl programs.
Re:Relevant p5p threads
torin on 2002-05-14T16:16:34
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.)Re:Relevant p5p threads
cjf on 2002-05-14T19:22:14
There was also a Thread on this over at Perlmonks a few days back.
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
rendhalver on 2002-05-15T10:07:54
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)Re:Finally
waldo on 2002-05-28T08:01:32
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 works for me, the system is about 95 megas of disk space, Perl is about 30 megas, is normal that developpers decide things like this. Perl is very easy to compile. The problem for me would be if they don't put the compiler, now there is a bit of problem because there are a lot of programs that use instructions of C++. I surmise that about 30 megas of space is the compiler, the new last version of the 3.03 GNU compiler more o less is.... I use a lot of programs from Linux of Perl is my particular CPAN, linking is a very great idea.
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 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.
FreeBSD couldn't justify that complexity and so they removed it and are porting the fifteen or so places in CORE that need it.
Perl is my hammer, and yes, all my problems look like nails, but I think this is a GOOD thing. Perl tied directly into the core of an OS is a BAD thing.
It's been an eventful week. FreeBSD extricates its core from perl and OpenBSD has removed rshd/rlogind/rexecd.
Re:It's not GONE, just delayered.
ziggy on 2002-05-15T23:51:32
<rant direction="omnidirectional">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.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.005_03. Anyone who has installed Perl before knows that the modules and extensions go in $PREFIX/lib/perl5/$VERSION[/$ARCH] and $PREFIX/lib/perl5/site_perl/$VERSION[$ARCH]. So long as you're not re-installing 5.005_03 with different compile-time options, you're OK, because the $VERSION component of the path differs. This is more likely than not to be the case, since 5.6.x has been around quite a long time.
Maintaining two Perls on a FreeBSD system is not a serious issue. It's not even an issue. The paths don't conflict (FreeBSD uses
/usr/libdata/perl5.00503 for core modules and /usr/local/lib/perl5/site_perl for 3rd-party modules), so as long as /usr/bin/perl and its immediate relatives point to the proper binary, there are no issues with conflicting module installations or partial module installations. I'm writing this on a FreeBSD box that I bought and configured back in the days of 3.3; it's currently running 4.5 (it was running 4.6-PRERELEASE yesterday, but there were some problems with mount(1) that I downgraded to fix). The installed ports are a mess (I'm still running XFree86 3.x), but the machine has survived many an upgrade thorugh cd
/usr/src && make at least a dozen times now. I will say that I have said D'OH! a few times when the hardlinks to
/usr/bin/perl get reset after a make world, but that's fixed by this magic incantation: cd /usr/src && make && fix-perl, where /usr/bin/fix-perl is this little hack: This is not rocket science. It's not even a hard problem to solve. If you're feeling rather cranky, it might rate as high as a minor annoyance.#!/bin/sh
rm -f/usr/bin/perl /usr/bin/perl5
ln/usr/bin/perl5.6.1 /usr/bin/perl
ln/usr/bin/perl5.6.1 /usr/bin/perl5 </rant>
Re:It's not GONE, just delayered.
ct on 2002-05-16T13:32:12
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 own a car with an oil burning problem. Instead of getting the head gasket replaced, I poured two quarts of oil in my car every monday before I drove to work. It worked. I drove that car for months in that state. It was trivial to add oil, and, since I bought the oil by the case, not really that expensive.
If you have to recompile a perl you don't use every time you want to recompile the core, you're wasting time. If that perl is only there for fourteen obscure system scripts which could trivially be rewritten in sh or C, the problem becomes even more ludicrous.
I'll admit, I'm a recent convert to the BSD world. I've been a Linux user since 1991, but only began playing with the BSD's in December, when I installed OpenBSD 3.0 on a spare box and liked it so much I made it my firewall. On a BSD kick I converted my dual processor fileserver to FreeBSD 4.4, which does no perl. I've found FreeBSD's
/usr/src and /usr/ports to be slightly different than OpenBSD, enough so that I don't do much with the box. The only thing it does, after all, is have a big hard drive, run samba, and run icecast which streams my mp3's at the icecast server on my firewall.
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.
