login
Search
Mark Murray recently started a thread on the "current" FreeBSD mailing list regarding "the future of Perl on FreeBSD". He says, "The recent removal of the CGI perl module from CURRENT started a very lively discussion on both the perl lists and some FreeBSD ones." The Perl community's complaint is that Perl should be included fully or not at all. The complaints against Perl include it's increasing size and the fact that FreeBSD as an OS makes little use of Perl.
Three possible solutions were suggested: 1) leave Perl in the base and deal with it. 2) split Perl into two pieces, base and libraries. 3) remove Perl and make it a port which a user can add as s/he wishes.
Most responses endorsed the third option, though there is work in making this possible. Matthew Dillon pointed out several core programs that use Perl, suggesting as a workaround adding a 'miniperl' to be included in base that these programs could point to, but that would not conflict in any way with the Perl port.
From: Mark Murray
Subject: The future of perl on FreeBSD
Date: Tue, 07 May 2002 23:41:00 +0100
Hi all
This is likely to be the mother of all bikesheds, so PLEASE
restrain yourselves!
The recent removal of the CGI perl module from CURRENT started
a very lively discussion on both the perl lists and some FreeBSD
ones.
The issues can be summarised as follows (interested parties, please
make sure I'm being honest here):
1) The perl community feel that perl is an "all-or-nothing" affair,
and a removal of any part of the distributed package is a violation
of the "perl contract" (not license - what folks expect).
2) Perl is growing very fast, and a future release of perl
is slated to be 45MB of source code. This is simply too much
for FreeBSD to use in the "base OS".
3) FreeBSD as an OS has had very modest perl needs. Not much more
than the core language (interpreter) is really needed for things
like building the kernel (moot point, the scripts are now rewritten
in awk/sh/C). There are some userland scripts, and those really only
need to core language to function (in most cases, any modules are
used for convenience). Today, FreeBSD does not need perl _at_ _all_
for a make world or to build the kernel.
There are some solutions:
1) leave perl in the base OS and deal with the library bloat.
PRO: does not violate "perl POLA", satisfies perl community.
Provides high-level scripting language in the base OS.
CON: bloody nightmare to maintain, fragile as hell, breaks.
will require that future library bloat from perl project
be taken; this is likely to be heavy.
2) split perl down to base language/interpreter for OS use, and
make the libraries a port.
PRO: supported by some senior(?) perl community committers (as
discussed on a perl list *NOTE* _NOT_ FreeBSD committers!),
who have proposed that perl be split into two main parts:
1) perl-base 2) perl-libraries. the base changes much
less than the libraries, and would be very suitable for
base OS's. perl-library is fairly mobile and would be
excellent ports-fodder.
CON: is not here yet (from perl crowd). We'd have to roll-our-
own in the meanwhile. base-perl is not "full-perl"
until a port (perl-library) is installed. the ports
collection will need some work to handle this.
I've already rolled a perl-base for FreeBSD/Perl-5.6.1 as a
proof of concept. It will not have the cross-build breakages
that the current kluge-up has. If wanted, I could commit it
straight away. I'd need to build a perl library to go with
this. This is a bit more work, but not hard.
3) Ditch perl from the base system completely, and rely on the
ports system for FreeBSD's perl requirements.
PRO: Speed up "make world", debloat source tree, prevent
many cross-build breakages.
CON: No high-level scripting system in the tree by default
(need to install a port to get one). The ports collection
will need some work to handle this.
I've tested a build of this, including kernel. Some apps
(like sockstat) break. I could commit this if it is wanted.
4) Other?
Please don't overly theorise here :-). We need engineering,
not philosophy.
Once this has been discussed, if there is a clear line of action,
I will take that, otherwise I may Call For Votes, or some such
tie-breaking action.
What say you?
*Dons fireproof underwear* :-)
M
--
o Mark Murray
_
O._ Warning: this .sig is umop ap!sdn
From: Maxime Henrion
Subject: Re: The future of perl on FreeBSD
Date: Tue, 7 May 2002 16:02:16 -0700
Mark Murray wrote:
[long explanation and other solutions ripped]
> 3) Ditch perl from the base system completely, and rely on the
> ports system for FreeBSD's perl requirements.
> PRO: Speed up "make world", debloat source tree, prevent
> many cross-build breakages.
> CON: No high-level scripting system in the tree by default
> (need to install a port to get one). The ports collection
> will need some work to handle this.
> I've tested a build of this, including kernel. Some apps
> (like sockstat) break. I could commit this if it is wanted.
Another possibility is to ditch perl from the base system and making it
a port, but still installing the port by default. This solves the only
"CON" for this solution. As already pointed out by desand brooks, this
is how Debian and Solaris are doing. Given that the Perl community
expressed no problems regarding the way Perl is distributed on these
two OS's as far as I know, we can probably assume that this solution
will also please the Perl community.
Thanks,
Maxime
Assuming the base utility issues can be addressed, I would go for #3.
A clean break would allow the perl community to focus on the port and
various flavors of same. If this cannot be accomplished then I
would recommend keeping an unadorned perl in the base system but
calling it something else, like resurrecting the notion of
'miniperl' and having the base utilities that use perl explicitly
specify /usr/bin/miniperl, and not having a /usr/bin/perl in the base
system at all... kind of a modified #3. If miniperl requires additional
library support the support would be put in a non-standard place so as not
to intefere with the ports perl *at *all*. i.e. we would not try to share
any portion of miniperl and perl. Amoung other things that would give us
a large safety margin in the face of major perl updates.
The base utility issue is mainly:
makewhatis, catman, sockstat, whereis, which, adduser, rmuser, kbdmap, pkg_update
-Matt
earth:/home/dillon# fgrep '#!/usr/bin/perl' `find /bin /sbin /usr/bin /usr/sbin /usr/libexec -type f`
/usr/bin/makewhatis:#!/usr/bin/perl
/usr/bin/catman:#!/usr/bin/perl
/usr/bin/pod2html:#!/usr/bin/perl
/usr/bin/pod2man:#!/usr/bin/perl
/usr/bin/pod2latex:#!/usr/bin/perl
/usr/bin/pod2text:#!/usr/bin/perl
/usr/bin/c2ph:#!/usr/bin/perl
/usr/bin/h2ph:#!/usr/bin/perl
/usr/bin/h2xs:#!/usr/bin/perl
/usr/bin/perlbug:#!/usr/bin/perl
/usr/bin/perlcc:#!/usr/bin/perl
/usr/bin/perldoc:#!/usr/bin/perl
/usr/bin/pl2pm:#!/usr/bin/perl
/usr/bin/splain:#!/usr/bin/perl
Binary file /usr/bin/a2p matches
/usr/bin/s2p:#!/usr/bin/perl
/usr/bin/s2p:$startperl = "#!/usr/bin/perl";
/usr/bin/find2perl:#!/usr/bin/perl
/usr/bin/find2perl:$startperl = "#!/usr/bin/perl";
/usr/bin/htags:#!/usr/bin/perl
/usr/bin/htags:#!/usr/bin/perl
/usr/bin/sockstat:#!/usr/bin/perl -w
/usr/bin/whereis:#!/usr/bin/perl
/usr/bin/which:#!/usr/bin/perl
/usr/bin/mmroff:#!/usr/bin/perl
/usr/sbin/adduser:#!/usr/bin/perl
/usr/sbin/rmuser:#!/usr/bin/perl
/usr/sbin/vidfont:#!/usr/bin/perl
/usr/sbin/kbdmap:#!/usr/bin/perl
/usr/sbin/spkrtest:#!/usr/bin/perl
/usr/sbin/pkg_update:#!/usr/bin/perl -w
From: Dag-Erling Smorgrav
Subject: Re: The future of perl on FreeBSD
Date: 08 May 2002 01:22:53 +0200
Matthew Dillon writes:
> The base utility issue is mainly:
>
> makewhatis, catman, sockstat, whereis, which, adduser, rmuser, kbdmap, pkg_update
catman is a joke, it should be an option to man(1).
sockstat is being rewritten in C
which is a C program and has been for ~2 years
adduser is pretty straightforward and can be rewritten in sh or C
rmuser is pretty straightforward and should be rewritten in sh
kbdmap is pretty straightforward and should be rewritten in C
pkg_update is pretty straightforward and should be rewritten in sh
DES
--
Dag-Erling Smorgrav
From: Matthew Dillon
Subject: Re: The future of perl on FreeBSD
Date: Tue, 7 May 2002 16:29:15 -0700 (PDT)
Well, ok... but the real issue here is not how easy it would be to
rewrite these utilities, but who will actually rewrite them and
when it will get done. If there are people lined up to do the
work then great! We can move ahead with idea #3. But if it isn't
likely to be done in the time frame Mark is thinking about it
might be best not to depend on the work getting done and going
with something like the miniperl idea as a temporary stopgap. The
nice thing about the miniperl idea is that it works great as a
temporary stopgap.. since only system utilities would use the
binary, when the last system utility is rewritten the miniperl
could simply be removed from the system entirely without affecting
anything or anyone.
-Matt
Matthew Dillon
At 4:09 PM -0700 5/7/02, Matthew Dillon wrote:
>:3) Ditch perl from the base system completely, and rely on
>: the ports system for FreeBSD's perl requirements.
>: PRO: Speed up "make world", debloat source tree, prevent
>: many cross-build breakages.
>: CON: No high-level scripting system in the tree by default
>: (need to install a port to get one). The ports
>: collection will need some work to handle this.
>: I've tested a build of this, including kernel. Some apps
>: (like sockstat) break. I could commit this if it is wanted.
>
> Assuming the base utility issues can be addressed, I would
> go for #3.
I prefer #3 too.
> If this cannot be accomplished then I would recommend
> keeping an unadorned perl in the base system but calling
> it something else, like resurrecting the notion of
> 'miniperl' and having the base utilities that use perl
> explicitly specify /usr/bin/miniperl, and not having
> a /usr/bin/perl in the base system at all... kind of a
> modified #3.
I would also be happy with this tactic. Another advantage of
this tactic is that developer who does change any of these
base-system perl scripts will be forced to do it in exactly the
same environment as the base system. Ie, they will not make a
change which happens to work on their system only because they
already have some group of libraries installed (from a port).
If there is any perl in the base system, it should be one which
is not AT ALL effected by any perl-related ports. The more I
think about this, the more I am convinced this idea of separation
is the right idea. (assuming we have any perl in the base-OS)
--
Garance Alistair Drosehn
Senior Systems Programmer
Rensselaer Polytechnic Institute
> 3) Ditch perl from the base system completely, and rely on the
> ports system for FreeBSD's perl requirements.
YESSSSS!!!!
> PRO: Speed up "make world", debloat source tree, prevent
> many cross-build breakages.
> CON: No high-level scripting system in the tree by default
> (need to install a port to get one). The ports collection
> will need some work to handle this.
The base system should be able to get by with sh/awk/sed like
it did before the Perl camel entered the tent.
If
- the core system was much smaller,
- there was a much tigher integration with ports, and
- there was a way to easily select which system configuration
*profile* you wanted to install or modify before installing,
a wide variety of users may be made happy. But this is a
separate & often repeated discussion, I guess!
-- bakul
I tend to be a fan of option #3 because it reduces maintenance load with
much the same result as having the maintenance cost. I have some
questions about compatibility.
First question is -- people are going to be upgrading FreeBSD. Having a
stale /usr/bin/perl is going to muck stuff up royally. Likewise, many
existing scripts use /usr/bin/perl at that location. Can we simply have a
symlink that points /usr/bin/perl at /usr/local/bin/perl (and any related
pseudo-programs such as suidperl, etc) as part of the normal install along
with the perl package. Likewise, it would be good to clear out the lib
stuff if we can to prevent the inevitable breakage there during the
upgrade. If we hook symlink creation into the build, that would also
force us buildworld/installworld'ers to install the package, which would
improve exposure. Do Perl applications typically hard code paths, or just
rely on Perl to "know where to look"?
Second -- are you volunteering to clean up the applications that are
as-yet unclaimed? DES has started on sockstat, and there's been an
on-going effort to fix the build to not need perl (now completed). Or at
least, can you coordinate the effort via a task list, etc?
Third -- is this something you envision hitting RELENG_4, or just 5.0? Is
any magic needed to reflect that? It's certainly not happening by 4.6 in
the -STABLE branch, but 4.7 could be a reality if we can be sure the
breakage will be low. However, for -STABLE trackers, we'll need a serious
heads up, updating entry, etc. They'll want to install the perl package
before they upgrade the system so as not to lose functionality.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[email filtered] NAI Labs, Safeport Network Services
> First question is -- people are going to be upgrading FreeBSD. Having a
> stale /usr/bin/perl is going to muck stuff up royally. Likewise, many
> existing scripts use /usr/bin/perl at that location. Can we simply have a
> symlink that points /usr/bin/perl at /usr/local/bin/perl (and any related
> pseudo-programs such as suidperl, etc) as part of the normal install along
> with the perl package.
DES(?) has a piece of code (to be called /usr/bin/perl) that will find the
"real" perl and DTRT.
> Likewise, it would be good to clear out the lib
> stuff if we can to prevent the inevitable breakage there during the
> upgrade. If we hook symlink creation into the build, that would also
> force us buildworld/installworld'ers to install the package, which would
> improve exposure. Do Perl applications typically hard code paths, or just
> rely on Perl to "know where to look"?
Perl knows where to look for its libraries. We have the precedent of
telnet cleaning out libtelnet; I'm sure we can put a temporary perl-
killer in some makefile (Part of "make installworld"? Part of mergemaster?)
to clean up.
> Second -- are you volunteering to clean up the applications that are
> as-yet unclaimed? DES has started on sockstat, and there's been an
> on-going effort to fix the build to not need perl (now completed). Or at
> least, can you coordinate the effort via a task list, etc?
If we go that route, no problem.
> Third -- is this something you envision hitting RELENG_4, or just 5.0?
NO WAY! CURRENT only.
On Tue, May 07, 2002 at 11:41:00PM +0100, Mark Murray wrote:
> Hi all
>
> This is likely to be the mother of all bikesheds, so PLEASE
> restrain yourselves!
Actually, I think people have been fairly restrained on this one, and
we're building a clear consensus. :-) Thanks for gritting your teeth
on this one and opening the discussion to the widest community
possible, and for listening to all this input.
As someone who uses both FreeBSD *and* Perl, I want whichever version
of Perl that I want. I want to be able to use my desired version of
Perl without dealing with workarounds or hacks. This is the same way
I want to use Apache or PHP, for example.
This means installing from a port, and not having to worry about
possible conflicts with the base system. #3.
==ml
CPAN is perls problem
I don't use perl regulary, but from time to time I download a perl script to test something. Very often I find that I have to install som new CPAN module to get the thing working, and almost every time I give up after 10 minutes because I can't get the "perl::very_useful_module_that_two_developers_in_the_whole_world_use" to install. I whish I could download a 10GB CPAN rpm to stop my troubles ...
Sure, perl is useful, but for an occasional user like me, it is too large.
automatic cpan
as root, do
perl -MCPAN -e 'install some::useful_module'
Stick with CPAN for perl libraries, not ports
With perl modules, one should stick with CPAN, not ports and especially not a mixture of CPAN and ports, otherwise errors due to version problems will result. I recommend using a port to install the base perl, but stick with CPAN after that. So, if the base perl is separated from the libraries, forget trying to write ports for the libraries. Just let perl users use CPAN for the libraries. It is less error prone and less work. Since CPAN is closer to the origination of the code, it is always more up to date and works better.
I once needed some Perl modules installed on a FreeBSD system for an application. I found some available as ports, and installed them when I installed other ports, then used CPAN to get the perl modules for which ports were not available. The result was several errors, apparently due to incorrect versions of dependent modules. I fixed the problem by using CPAN to reinstall several modules that I had previously installed using ports.
Ugly typo
>The complaints against Perl include it's increasing size and the fact
>that FreeBSD as an OS makes little use of Oerl.
note the typo.
btw, should typo reports be "filed" as comments, or would you rather have them sent by email or the prvmsg system?
Re: Ugly typo
A private message would be preferred, as once I fix the typo the comments usually cease to make sense.
Better yet, I should get an editor to help me stop making typos!
Thanks...
openssh next?
I hope to god they remove OpenSSH from the base next; I'm tired of all the hoops I have to jump to upgrade OpenSSH and not muck with the base install.
Hmmm...
good that I saw this, so that if I want to use BSD again .. to use other distro..