The future of perl on FreeBSD
Mark Murray
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
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Maxime Henrion
[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
Matthew Dillon
:*Dons fireproof underwear* :-)
:
:M
:--
:o Mark Murray
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
Alfred Perlstein
> Hi all
>
>
> There are some solutions:
>
> 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.
Have sysinstall automagically install perl as a package
and this should work fine.
--
-Alfred Perlstein [alf...@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
Bakul Shah
> 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
Dag-Erling Smorgrav
> 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 - d...@ofug.org
Matthew Dillon
:
:Matthew Dillon <dil...@apollo.backplane.com> 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 - d...@ofug.org
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
<dil...@backplane.com>
Garance A Drosihn
>: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.
>
> 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 = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
Robert Watson
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
rob...@fledge.watson.org NAI Labs, Safeport Network Services
John Baldwin
On 07-May-2002 Mark Murray 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.
I would vote for this and the suggestion some other folks made earlier
that perl be installed by default by sysinstall except that a user
could go into the custom menu and disable it if they wished.
--
John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Jun Kuriyama
John Baldwin wrote:
> Hmm, the printf's just before the panic message would be nice. :-/
Sorry. Here it is:
recursed on non-recursive lock (sleep mutex) UMA Buckets @../../../vm/uma_core.
c:1467
first acquired @ ../../../vm/uma_core.c:583
> Can you get lock1->li_file and lock1->li_line out of frame 11?
> The string at lock1->li_file would be needed not just the pointer
> value.
(kgdb) p lock1->li_file
$1 = 0xc02e9b11 "../../../vm/uma_core.c"
(kgdb) p lock1->li_line
$2 = 583
--
Jun Kuriyama <kuri...@imgsrc.co.jp> // IMG SRC, Inc.
<kuri...@FreeBSD.org> // FreeBSD Project
Peter Wemm
> sockstat is being rewritten in C
Yes, regardless of the status of perl. :-)
> adduser is pretty straightforward and can be rewritten in sh or C
> rmuser is pretty straightforward and should be rewritten in sh
These should be sh wrappers around 'pw useradd' and 'pw userdel'. There
is no need to reinvent pw(8) in perl as well.
> pkg_update is pretty straightforward and should be rewritten in sh
pkg_update should probably be cvs rm'ed and replaced by the portupgrade
package from the ports collection.
As for perl itself, I have 100% changed my views on it. I was once firmly
in the 'perl must be in the base' camp, but I now think it should be
a port where we can do a proper job of it.
Cheers,
-Peter
--
Peter Wemm - pe...@wemm.org; pe...@FreeBSD.org; pe...@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Peter Wemm
> 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"?
We have several choices.. From installing a symlink pointing to wherever
the default perl package is, through to a simple redirector that searches
$PATH and/or looks in a few well-known locations. Heck, python often uses
"#! /usr/bin/env python". This works for perl scripts too.
Cheers,
-Peter
--
Peter Wemm - pe...@wemm.org; pe...@FreeBSD.org; pe...@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Mark Murray
> 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.
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to majo...@FreeBSD.org
Josef Karthauser
>
> pkg_update should probably be cvs rm'ed and replaced by the portupgrade
> package from the ports collection.
>
We can't replace it with portupgrade in the base system, because
portupgrade is implemented in ruby, which isn't in the base system.
Joe
Emiel Kollof
[snip]
> 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.
Ohhh... yes please. This will shrink the base system and the base system
sources by quite a bit. I like it. Don't mind installing perl on a machine
via a port when I need it. And useradd(1) I did myself once in C (not really
usable for in the distribution, and my C code stinks anyway :) so that should
be trivial to do.
I say ditch it. You are absolutely welcome to.
Cheers,
Emiel
--
Bob Bishop
Mark Murray (ma...@grondar.za) wrote:
>[...]
>
>3) Ditch perl from the base system completely, and rely on the
> ports system for FreeBSD's perl requirements.[etc]
Yeah. And don't think twice.
--
Bob Bishop +44 (0)118 977 4017
r...@gid.co.uk fax +44 (0)118 989 4254
Michael Lucas
> 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
--
Michael Lucas mwl...@FreeBSD.org, mwl...@BlackHelicopters.org
http://www.oreillynet.com/pub/q/Big_Scary_Daemons
Absolute BSD: http://www.nostarch.com/abs_bsd.htm
Matt Loschert
> 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
Not that my opinion matters much, but just for the record, I agree 100%
with Michael. Perl and FreeBSD make for a near-perfect development
environment, but the hassle of maintaining and upgrading them correctly,
when one contains the other, makes for a giant PITA. Hopefully, we can
remove all system dendencies on Perl and offer users a well-maintained
port of Perl instead.
- Matt
--
Matt Loschert - Software Engineer | email: losc...@servint.com |
ServInt Internet Services | web: http://www.servint.net/ |
McLean, Virginia USA | phone: (703) 847-1381 |
Mark Murray
> are proposing. I would like to seek clarification on one point you made
> though if I may:
>
> > 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.
>
> Apologies if I'm being dumb.
It runs fine, but the build is very fragile in cross-builds, OS upgrades,
OS reinstalls and so on. Its all in the generated library makefiles,
staring with DynaLoader - these makefiles are very sensitive to the
environment they were generated in, and are not tolerant of a BSD
make environment when a make -DNOCLEAN is done or a make install is
done over NFS where directory paths aren't the same as for the build.
Perl builds have the habit of turning build-time options into run-time
defaults, and overriding this is Hard.
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf
GB Clark
On Wed, 08 May 2002 00:51:12 -0700
Peter Wemm <pe...@wemm.org> wrote:
> >Dag-Erling Smorgrav wrote:
<SNIP>
>
> pkg_update should probably be cvs rm'ed and replaced by the portupgrade
> package from the ports collection.
So you want to take out perl and replace it with ruby? The portupgrade
package is a ruby script, not C.
GB
--
GB Clark II | Roaming FreeBSD Admin
gcla...@VSServices.COM | General Geek
CTHULU for President - Why choose the lesser of two evils?
Garrett Rooney
>
> On Wed, 08 May 2002 00:51:12 -0700
> Peter Wemm <pe...@wemm.org> wrote:
> > >Dag-Erling Smorgrav wrote:
> <SNIP>
> > > pkg_update is pretty straightforward and should be rewritten in sh
> >
> > pkg_update should probably be cvs rm'ed and replaced by the portupgrade
> > package from the ports collection.
> <SNIP>
>
> So you want to take out perl and replace it with ruby? The portupgrade
> package is a ruby script, not C.
i think he meant that we should remove it, and if people want the
functionality they should be directed to install the portupgrade
package from ports. it works much better than pkg_update anyway, i
even recall seeing a post from the original author of pkg_update
saying just that a while back.
-garrett
--
garrett rooney Remember, any design flaw you're
roo...@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
Bruce A. Mah
> On Wed, May 08, 2002 at 03:55:01AM -0500, GB Clark wrote:
> > So you want to take out perl and replace it with ruby? The portupgrade
> > package is a ruby script, not C.
>
> i think he meant that we should remove it, and if people want the
> functionality they should be directed to install the portupgrade
> package from ports. it works much better than pkg_update anyway, i
> even recall seeing a post from the original author of pkg_update
> saying just that a while back.
I don't know if the author of pkg_update has ever said that, but the
author of pkg_version (yours truly) has said something like this on
multiple occasions (with respect to pkg_version's -c option).
Oh yes, pkg_version will need to be rewritten too, because it uses Perl.
I don't know how hard that will be...I haven't even looked at the code
in over a year. I don't have any interest in doing this, but I'm sure
one of you src/ gurus can whip something up. :-)
Bruce.
Garrett Rooney
> If memory serves me right, Garrett Rooney wrote:
> > On Wed, May 08, 2002 at 03:55:01AM -0500, GB Clark wrote:
>
> > > So you want to take out perl and replace it with ruby? The portupgrade
> > > package is a ruby script, not C.
> >
> > i think he meant that we should remove it, and if people want the
> > functionality they should be directed to install the portupgrade
> > package from ports. it works much better than pkg_update anyway, i
> > even recall seeing a post from the original author of pkg_update
> > saying just that a while back.
>
> I don't know if the author of pkg_update has ever said that, but the
> author of pkg_version (yours truly) has said something like this on
> multiple occasions (with respect to pkg_version's -c option).
that may have been what i was thinking of. if so, appologies to the
author of pkg_update for misquoting him.
-garrett
--
garrett rooney Remember, any design flaw you're
roo...@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
To Unsubscribe: send mail to majo...@FreeBSD.org
Peter Wemm
>
> On Wed, 08 May 2002 00:51:12 -0700
> Peter Wemm <pe...@wemm.org> wrote:
> > >Dag-Erling Smorgrav wrote:
> <SNIP>
> > > pkg_update is pretty straightforward and should be rewritten in sh
> >
> > pkg_update should probably be cvs rm'ed and replaced by the portupgrade
> > package from the ports collection.
> <SNIP>
>
> So you want to take out perl and replace it with ruby? The portupgrade
> package is a ruby script, not C.
No, remove pkg_update from the base and point people to the portupgrade
package instead.
Cheers,
-Peter
--
Peter Wemm - pe...@wemm.org; pe...@FreeBSD.org; pe...@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Paul Richards
> > 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.
I much prefer the symlink approach. I don't think some wrapper program
in the base tree buys us anything. You might as well have nothing sit in
the /usr/bin/perl position, and have the port create the symlink.
It's a bit unusual for a port to do that but I think this is a special
case.
--
Paul Richards | FreeBSD DVD releases and merchandise.
FreeBSD Services Ltd | Hardware, support and development.
http://www.freebsd-services.com | Domain names and mail/web hosting.
George Cox
> > improve exposure. Do Perl applications typically hard code paths, or just
> > rely on Perl to "know where to look"?
>
> We have several choices.. From installing a symlink pointing to wherever
> the default perl package is, through to a simple redirector that searches
> $PATH and/or looks in a few well-known locations. Heck, python often uses
> "#! /usr/bin/env python". This works for perl scripts too.
We have mailwrapper(1). How about perlwrapper(1)?! h0h0h0
best;
gjvc
--
[gjvc]
David W. Chapman Jr.
> On 08/05 00:55, Peter Wemm wrote:
>
> > > improve exposure. Do Perl applications typically hard code paths, or just
> > > rely on Perl to "know where to look"?
> >
> > We have several choices.. From installing a symlink pointing to wherever
> > the default perl package is, through to a simple redirector that searches
> > $PATH and/or looks in a few well-known locations. Heck, python often uses
> > "#! /usr/bin/env python". This works for perl scripts too.
>
> We have mailwrapper(1). How about perlwrapper(1)?! h0h0h0
mailwrapper is because FreeBSD comes with an MTA though.
No h0h0h0 magic! :)
--
David W. Chapman Jr.
dw...@inethouston.net Raintree Network Services, Inc. <www.inethouston.net>
dw...@freebsd.org FreeBSD Committer <www.FreeBSD.org>
Tony Finch
Peter Wemm <pe...@wemm.org> wrote:
>
> We have several choices.. From installing a symlink pointing to wherever
> the default perl package is, through to a simple redirector that searches
> $PATH and/or looks in a few well-known locations. Heck, python often uses
> "#! /usr/bin/env python". This works for perl scripts too.
Perl is much more frequently run with arguments on the shebang line,
typically "#!/usr/bin/perl -w", and "#!/usr/bin/env perl -w" isn't
portable to systems other than FreeBSD (which has an extension of
traditional shebang handling) so is unlikely to get wide acceptance.
<http://www.uni-ulm.de/~s_smasch/various/shebang/> is recommended.
Tony.
--
f.a.n.finch <d...@dotat.at> http://dotat.at/
SOUTHEAST ICELAND: SOUTHEASTERLY 5 OR 6 VEERING SOUTHWESTERLY 3 OR 4. RAIN
CLEARING. MODERATE BECOMING GOOD.
Chip Marshall
> On Wed, May 08, 2002 at 06:55:16PM +0000, George Cox wrote:
> > We have mailwrapper(1). How about perlwrapper(1)?! h0h0h0
>
> mailwrapper is because FreeBSD comes with an MTA though.
Speaking of which, if we want to rip perl out of the base system, why
not rip sendmail out too? Allow it to be an install-time option as to
which MTA to use, be it sendmail, postfix, qmail, or whathaveyou.
--
Chip Marshall <ch...@chocobo.cx> http://www.chocobo.cx/chip/
GCM/CS d+(-) s+:++ a20>? C++ UB++++$ P+++$ L- E--- W++ N@ o K- w O M+
V-- PS+ PE Y+ PGP++ t+@ R@ tv@ b++@ DI++++ D+(-) G++ e>++ h>++ r++ y?
David O'Brien
> On May 08, 2002, David W. Chapman Jr. sent me the following:
> > On Wed, May 08, 2002 at 06:55:16PM +0000, George Cox wrote:
> > > We have mailwrapper(1). How about perlwrapper(1)?! h0h0h0
> >
> > mailwrapper is because FreeBSD comes with an MTA though.
>
> Speaking of which, if we want to rip perl out of the base system, why
> not rip sendmail out too? Allow it to be an install-time option as to
> which MTA to use, be it sendmail, postfix, qmail, or whathaveyou.
T CHIP STAY ON TOPIC K PLZ THNX!! The topic is _P-E-R-L_
Chip Marshall
> On Wed, May 08, 2002 at 05:00:30PM -0400, Chip Marshall wrote:
> > Speaking of which, if we want to rip perl out of the base system, why
> > not rip sendmail out too? Allow it to be an install-time option as to
> > which MTA to use, be it sendmail, postfix, qmail, or whathaveyou.
>
> T CHIP STAY ON TOPIC K PLZ THNX!! The topic is _P-E-R-L_
>
Umm... kay. I'm glad to see we found the cap-lock before the end of
that line. Anyway, I think it's a valid point. How much software
should be included in the base system, really?
From my brief Linux experience, it seems some distros put a lot of
junk in that most people don't need.
NetBSD on the other hand, put nearly nothing in the base system.
What should FreeBSD really be doing? I see perl as being a nice thing
to have, but not everyone needs it, and it is a pain to maintain
(apparently), and it is big. Should other big pieces of software that
are currently in the base system be removed and put into an optional
package arrangement?
Dag-Erling Smorgrav
> We have several choices.. From installing a symlink pointing to wherever
> the default perl package is, through to a simple redirector that searches
> $PATH and/or looks in a few well-known locations.
As previously posted...
DES
--
Dag-Erling Smorgrav - d...@ofug.org
Robert Watson
> On May 08, 2002, David W. Chapman Jr. sent me the following:
> > On Wed, May 08, 2002 at 06:55:16PM +0000, George Cox wrote:
> > > We have mailwrapper(1). How about perlwrapper(1)?! h0h0h0
> >
> > mailwrapper is because FreeBSD comes with an MTA though.
>
> Speaking of which, if we want to rip perl out of the base system, why
> not rip sendmail out too? Allow it to be an install-time option as to
> which MTA to use, be it sendmail, postfix, qmail, or whathaveyou.
This isn't a general discussion of architecture. This is a specific
discussion of one piece of software. Rather than drag in the larger
decision making issue, let's make progress on this one issue and deal with
the rest later.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
rob...@fledge.watson.org NAI Labs, Safeport Network Services
Garance A Drosihn
>Peter Wemm <pe...@wemm.org> writes:
> > We have several choices.. From installing a symlink
> > pointing to wherever the default perl package is,
> > through to a simple redirector that searches
> > $PATH and/or looks in a few well-known locations.
>
>As previously posted...
Here at RPI, we do something similar to this for some of
the interpretters we provide (both for shells and things
like perl). Our redirector-program is about 600 lines,
but some of that is to handle multi-platform issues, and
some of the rest is probably overkill.
Still, you probably want a more complicated re-direction
program than the one you posted. People will invoke a
script by invoking the script (okay, that sounds stupid,
but...), not by making sure their PATH has the right perl
in it. People might fully-specify the script to run, and
still have unintended consequences because there is some
other program named 'perl' somewhere in their path. In
many situations this is not an issue, but at other times
it can open some subtle security issues.
One of the nice things about using a redirector program,
though, is that it also allows the user a way to set which
version of perl they want to use, even if multiple copies
of perl are installed, and they can do it on a session-by-
session basis. That's the reason we did it at RPI. The
idea has proved to be very useful over the past nine years.
The code we still use at RPI would be a mess to use for
this freebsd idea, but I could write up something halfway
between DES's example and RPI's code if people would be
curious to see it. But I don't know if we want to start
yet another bikeshed if we haven't finished the last one...
--
Garance Alistair Drosehn = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
Mark Murray
>
> Peter Wemm <pe...@wemm.org> writes:
> > We have several choices.. From installing a symlink pointing to wherever
> > the default perl package is, through to a simple redirector that searches
> > $PATH and/or looks in a few well-known locations.
>
> As previously posted...
I like this util, but I think it shouldn't be perl-specific. How about
if it used argv[0] to find out what it is called, and used that to launch
the real interpreter (whichever interpreter - perl, suidperl, ruby etc).
There's need to be a bit of security checking too (buffers, appropriate
paths and so on). Maybe a config file for things like ${PREFIX}?
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to majo...@FreeBSD.org
Jeremy Lea
On Wed, May 08, 2002 at 09:08:32AM -0700, Bruce A. Mah wrote:
> Oh yes, pkg_version will need to be rewritten too, because it uses Perl.
> I don't know how hard that will be...I haven't even looked at the code
> in over a year. I don't have any interest in doing this, but I'm sure
> one of you src/ gurus can whip something up. :-)
I'll see if I can do something this weekend. It'll be in C, and make
the version comparison part of the library.
I'm not going to look at pkg_upgrade, because people are using
portupgrade instead.
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
Mark Murray
Thanks to all participants in this thread, the way ahead is now
abundantly clear. :-)
There were three options, listed below and trimmed:
> 1) leave perl in the base OS and deal with the library bloat.
> 2) split perl down to base language/interpreter for OS use, and
> make the libraries a port.
> 3) Ditch perl from the base system completely, and rely on the
> ports system for FreeBSD's perl requirements.
Option 1 got extremely limited support.
Option 2 got some support (and for the record it was my choice).
Option 3 got pretty overwhelming support.
So it looks like FreeBSD gets to ditch perl from the OS. I will do this.
There are some issues to deal with.
1) There are some perl scripts in the base OS that need to be either
ditched or rewritten.
2) The exact method of providing perl to the user base needs to be
rounded off. Here are some suggestions for this:
a) Rely entirely on the port and leave it at that.
b) Install the port at install time in a similar way to the
way we currently install XFree86.
c) Install a wrapper in /usr/bin/perl that runs the real
perl from whereever it is.
3) Fix the ports system such that USE_PERL makes an appropriate
dependancy on the perl port, and does not assume perl in the
base OS.
4) Fix ports that do things like "perl -spi -e '<script>' <files>"
to use whatever comes out of the current "sed -[Ii]" discussion
instead.
Any _strong_ feelings on any of these? Any volunteers?
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to majo...@FreeBSD.org
Alfred Perlstein
>
> So it looks like FreeBSD gets to ditch perl from the OS. I will do this.
Woohoo!
> There are some issues to deal with.
>
> 1) There are some perl scripts in the base OS that need to be either
> ditched or rewritten.
Yes.
> 2) The exact method of providing perl to the user base needs to be
> rounded off. Here are some suggestions for this:
> a) Rely entirely on the port and leave it at that.
> b) Install the port at install time in a similar way to the
> way we currently install XFree86.
> c) Install a wrapper in /usr/bin/perl that runs the real
> perl from whereever it is.
b makes the most sense as long as it's optional.
> 3) Fix the ports system such that USE_PERL makes an appropriate
> dependancy on the perl port, and does not assume perl in the
> base OS.
> 4) Fix ports that do things like "perl -spi -e '<script>' <files>"
> to use whatever comes out of the current "sed -[Ii]" discussion
> instead.
Both points are valid, but fixing can come later, rather than waiting
for 1000s of packages to be fixed, just do the switch, we'll catch
up. :)
> Any _strong_ feelings on any of these? Any volunteers?
Just 'phk' it, people will be forced to clean up.
--
-Alfred Perlstein [alf...@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
Richard Arends
On Thu, 9 May 2002, Mark Murray wrote:
> 1) There are some perl scripts in the base OS that need to be either
> ditched or rewritten.
Can somebody, or maybe you, make a list off the perl script in the base
OS, that need to be rewritten??
Greetings,
Richard.
----
An OS is like swiss cheese, the bigger it is, the more holes you get!
David Xu
From: "Mark Murray" <ma...@grondar.za>
To: <cur...@FreeBSD.ORG>
Sent: Thursday, May 09, 2002 5:31 PM
Subject: Resolution (Was: Re: The future of perl on FreeBSD)
> Hello all
> ...
> So it looks like FreeBSD gets to ditch perl from the OS. I will do =
this.
>
Congratulation! go ahead, I like the decision.
David Xu
Mark Murray
> > ditched or rewritten.
>
> Can somebody, or maybe you, make a list off the perl script in the base
> OS, that need to be rewritten??
Of course! :). Done, sent to current@
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf
To Unsubscribe: send mail to majo...@FreeBSD.org
Richard Arends
> > Can somebody, or maybe you, make a list off the perl script in the base
> > OS, that need to be rewritten??
>
> Of course! :). Done, sent to current@
Perfect...
What is preffered: C, Shell ???
Greetings,
Richard.
----
An OS is like swiss cheese, the bigger it is, the more holes you get!
John Baldwin
On 09-May-2002 Mark Murray wrote:
> 3) Fix the ports system such that USE_PERL makes an appropriate
> dependancy on the perl port, and does not assume perl in the
> base OS.
What I would do is wait to add these until 4) is done. Since this
only affects current the ports developers can manually install perl
if needed while doing the fixup.
Not a super strong feeling though.
--
John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
John Baldwin
On 09-May-2002 Richard Arends wrote:
> On Thu, 9 May 2002, Mark Murray wrote:
>
>> > Can somebody, or maybe you, make a list off the perl script in the base
>> > OS, that need to be rewritten??
>>
>> Of course! :). Done, sent to current@
>
> Perfect...
>
> What is preffered: C, Shell ???
Something that works. :)
--
John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majo...@FreeBSD.org
Dag-Erling Smorgrav
> I like this util, but I think it shouldn't be perl-specific. How about
> if it used argv[0] to find out what it is called, and used that to launch
> the real interpreter (whichever interpreter - perl, suidperl, ruby etc).
Don't turn this into a bikeshed 8) Let's commit it as-is, we can
always modify it later.
DES
--
Dag-Erling Smorgrav - d...@ofug.org
To Unsubscribe: send mail to majo...@FreeBSD.org
Mark Murray
>
> Perfect...
>
> What is preffered: C, Shell ???
The right tool for the right job. For wrapper type things that may be
shellscript, for more standalone tasks, I guess C. The programmer doing
the actual work has a lot of say in this, of course!
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to majo...@FreeBSD.org
Mark Murray
> > I like this util, but I think it shouldn't be perl-specific. How about
> > if it used argv[0] to find out what it is called, and used that to launch
> > the real interpreter (whichever interpreter - perl, suidperl, ruby etc).
>
> Don't turn this into a bikeshed 8) Let's commit it as-is, we can
> always modify it later.
NP :-)
I'll leave this one entirely to you. When I nuke perl, you step in
and commit this. OK?
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to majo...@FreeBSD.org
Dag-Erling Smorgrav
> I'll leave this one entirely to you. When I nuke perl, you step in
> and commit this. OK?
OK :)
DES
--
Dag-Erling Smorgrav - d...@ofug.org
To Unsubscribe: send mail to majo...@FreeBSD.org
Paul Richards
> Mark Murray <ma...@grondar.za> writes:
> > I'll leave this one entirely to you. When I nuke perl, you step in
> > and commit this. OK?
>
> OK :)
Does having this redirector serve any useful purpose? It's an extra
piece of code to maintain, it's an extra potential security risk, it's
an extra source of potential confusion to the Perl user if there's a bug
in it, and I can't see any useful purpose in it existing.
Either /usr/bin/perl is there or it isn't, we don't need a fancy
redirector to tell us it's not installed.
A symlink is a much more sensible solution to this problem and a
redirector just seems to be creating a toy for the fun of it rather than
to solve any real problem.
--
Paul Richards | FreeBSD DVD releases and merchandise.
FreeBSD Services Ltd | Hardware, support and development.
http://www.freebsd-services.com | Domain names and mail/web hosting.
Mark Murray
> piece of code to maintain, it's an extra potential security risk, it's
> an extra source of potential confusion to the Perl user if there's a bug
> in it, and I can't see any useful purpose in it existing.
>
> Either /usr/bin/perl is there or it isn't, we don't need a fancy
> redirector to tell us it's not installed.
>
> A symlink is a much more sensible solution to this problem and a
> redirector just seems to be creating a toy for the fun of it rather than
> to solve any real problem.
I'm completely ambivalent on this point. Symlink or redirector; I
don't mind. Once perl5 is out of the system cleanly, I'll consider
my job done.
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to majo...@FreeBSD.org
Maxime Henrion
> > Does having this redirector serve any useful purpose? It's an extra
> > piece of code to maintain, it's an extra potential security risk, it's
> > an extra source of potential confusion to the Perl user if there's a bug
> > in it, and I can't see any useful purpose in it existing.
> >
> > Either /usr/bin/perl is there or it isn't, we don't need a fancy
> > redirector to tell us it's not installed.
> >
> > A symlink is a much more sensible solution to this problem and a
> > redirector just seems to be creating a toy for the fun of it rather than
> > to solve any real problem.
>
> I'm completely ambivalent on this point. Symlink or redirector; I
> don't mind. Once perl5 is out of the system cleanly, I'll consider
> my job done.
It seems to me that if we are going to install perl by default, the
usefulness of a redirector is slight IMHO. If people don't have perl
installed it means they have disabled it themselves since it's in the
default install; so they should know that they need to install the port
if they finally decided they need it. If judged necessary, that could
be explained during the installation.
I wouldn't like to start a new bikeshed now that we went to a concensus,
so I here is one kind of compromise. We could have the redirector for
now, so that people who disabled it without knowing or, for some reason,
disabled it but were still expecting it to be here can get it right and
remove it for 6.0 in the favor of a symlink.
Thanks,
Maxime
Bruce A. Mah
> On Wed, May 08, 2002 at 09:08:32AM -0700, Bruce A. Mah wrote:
> > Oh yes, pkg_version will need to be rewritten too, because it uses Perl.
> > I don't know how hard that will be...I haven't even looked at the code
> > in over a year. I don't have any interest in doing this, but I'm sure
> > one of you src/ gurus can whip something up. :-)
>
> I'll see if I can do something this weekend. It'll be in C, and make
> the version comparison part of the library.
Great...thanks!
> I'm not going to look at pkg_upgrade, because people are using
> portupgrade instead.
Last I looked, it's been cvs rm'ed anyways.
Bruce.
Joseph Scott
On Thu, 9 May 2002, Mark Murray wrote:
# > Does having this redirector serve any useful purpose? It's an extra
# > piece of code to maintain, it's an extra potential security risk, it's
# > an extra source of potential confusion to the Perl user if there's a bug
# > in it, and I can't see any useful purpose in it existing.
# >
# > Either /usr/bin/perl is there or it isn't, we don't need a fancy
# > redirector to tell us it's not installed.
# >
# > A symlink is a much more sensible solution to this problem and a
# > redirector just seems to be creating a toy for the fun of it rather than
# > to solve any real problem.
#
# I'm completely ambivalent on this point. Symlink or redirector; I
# don't mind. Once perl5 is out of the system cleanly, I'll consider
# my job done.
This may sound like an extremely silly little idea, but is there
any reason why we can't just replace /usr/bin/perl with a shell script
that prints out something like :
Perl is no longer comes with the base install of FreeBSD, please install
it from your ports collection, in /usr/ports/lang/perl5.
-Joseph
Dag-Erling Smorgrav
> I wouldn't like to start a new bikeshed now that we went to a concensus,
> so I here is one kind of compromise. We could have the redirector for
> now, so that people who disabled it without knowing or, for some reason,
> disabled it but were still expecting it to be here can get it right and
> remove it for 6.0 in the favor of a symlink.
Thank you. EOD.
DES
--
Dag-Erling Smorgrav - d...@ofug.org
To Unsubscribe: send mail to majo...@FreeBSD.org
Sheldon Hearn
On Thu, 09 May 2002 08:24:57 MST, Joseph Scott wrote:
> This may sound like an extremely silly little idea, but is there
> any reason why we can't just replace /usr/bin/perl with a shell script
> that prints out something like :
>
> Perl is no longer comes with the base install of FreeBSD, please install
> it from your ports collection, in /usr/ports/lang/perl5.
We don't want the port to overwrite a script that exists in userland,
and we don't want installworld blowing away (or, even worse, following)
the port's symlink.
Symlink or redirector, but please not this. :-)
Ciao,
Sheldon.
Riccardo Torrini
> This may sound like an extremely silly little idea, but is there
> any reason why we can't just replace /usr/bin/perl with a shell
> script that prints out something like :
> Perl is no longer comes with the base install of FreeBSD, please
> install it from your ports collection, in /usr/ports/lang/perl5.
Or even better that check for existence of port, when true exec
.../local/bin/perl, when false print this message (like wish ?)
Riccardo.
Gerhard Sittig
>
> One of the nice things about using a redirector program,
> though, is that it also allows the user a way to set which
> version of perl they want to use, even if multiple copies
> of perl are installed, and they can do it on a session-by-
> session basis. That's the reason we did it at RPI. The
> idea has proved to be very useful over the past nine years.
This sounds to me like a "conditional" mailwrapper(8). :)
Having an /etc/perlwrapper.conf and a perlwrapper installed in
/usr/bin/perl would enable the admin to point to the installed
version of perl (the core interpreter which came with the base
system, a fullblown version from ports with lots of libs, an
experimental version from the perl development tree, a customized
version from whatever source, who knows? who cares?).
BTW do I consider the '#!' notion important and wouldn't suggest
any approach where the perl interpreter isn't called by the name
"/usr/bin/perl".
Since perl is not as systemwidely unique as an MTA is, the next
step could be to support ~/.perlwrapper.conf so users can switch
to a different interpreter without changing their PATH or every
script or even bothering the admin and thus every other user on
the system.
In case the interpreter to be invoked should be changable at any
random invocation (is demand for this so strong or is it just
"nice to have"?) the approatch could be to support conditions or
sections in the perlwrapper.conf syntax. Imagine something like
this:
----- perlwrapper.conf -------------------------------------
# section specified in $PERLWRAPPER_SECTION is used,
# "perlbase" by default (if ^^^ is empty or unset)
[perlbase]
perl /usr/bin/miniperl
suidperl /bin/false
[perlport]
perl /usr/local/bin/perl
suidperl /usr/local/bin/suidperl
------------------------------------------------------------
This would allow a user to work by default with what the admin
suggests but still be able to switch to a different interpreter
by calling `env PERLWRAPPER_SECTION=perlport /path/to/script`.
Should sections and or conditions be too hard to support for their
gain (or deviation from the current mailer.conf(5) syntax be too
bad a thing for reasons of a uniform wrapper program) the search
path could be expanded if it's already not just one file but a path
to search: $PERLWRAPPER_CONF:~/.perlwrapper.conf;/etc/perlwrapper.conf.
To summarize: Copying current mailwrapper's functionality for a
perlwrapper executable allows to ship the FreeBSD base with a core
language interpreter called "miniperl" (I understand we already
have this one) while calling the interpreter "/usr/bin/perl" is
still given. This would be no different from the current state
but provides the infrastructure for later extensions:
Installing a perl port and adjusting /etc/perlwrapper.conf should
be easy for an admin who wishes to use a newer or bigger (more
complete in the Perl community's view) or simply a different
interpreter.
For more customization under the users' control there's still
the option of implementing the perlwrapper.conf search path or
supporting sections or conditions in the config file (while the
search path seems to be the more sensible and intuitive approach).
BTW will updates in the config file as well as search path
variables in login or boot scripts be caught by mergemaster.
Symlinks are too easily destroyed by upgrading a system. I feel
configuring a system by editing /etc files is the traditional UNIX
way and thus more transparent and portable (diffable, patchable,
easily archived, distributed and applied).
The cost of parsing a five line text file when handing a
programming language script to an interpreter(!) seems acceptable
to me. The cost of following a symlink seems to be identical to
exec(3)uting a configured command with a known name. There is
only the additional cost of looking up and reading the one config
file for the unmodified base version as it will be shipped (the
above miniperl scenario). Only when implementing the search path
there is an additional missing lookup should the user not have an
~/.perlwrapper.conf file (making it two lookups and one read in
total). <not too serious> This could be speedup by importing
DJB's cdb code or some other fast database and using
"${PERLWRAPPER_CONF}${0}" for the index when looking up the
program to execute. </not too serious>
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard...@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
David O'Brien
On Thu, May 09, 2002 at 10:31:42AM +0100, Mark Murray wrote:
> 4) Fix ports that do things like "perl -spi -e '<script>' <files>"
> to use whatever comes out of the current "sed -[Ii]" discussion
> instead.
Why?? If someone wants to use perl in building a port, let them.
Add a BUILD_DEPENDS.
David O'Brien
On Thu, May 09, 2002 at 02:17:55PM +0100, Paul Richards wrote:
> A symlink is a much more sensible solution to this problem and a
> redirector just seems to be creating a toy for the fun of it rather than
> to solve any real problem.
A symlink to where?? You may not assume /usr/local.
Miguel Mendez
> > A symlink is a much more sensible solution to this problem and a
> > redirector just seems to be creating a toy for the fun of it rather than
> > to solve any real problem.
>
> A symlink to where?? You may not assume /usr/local.
IMHO the symlink should only be created by the perl port install, so ${PREFIX}
is honoured.
Cheers,
--
Miguel Mendez - fl...@energyhq.homeip.net
GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
EnergyHQ :: http://www.energyhq.tk
FreeBSD - The power to serve!
Gordon Tetlow
> [bogus From: address, because people cannot be bothered to respect Reply-To:]
>
> On Thu, May 09, 2002 at 10:31:42AM +0100, Mark Murray wrote:
> > 4) Fix ports that do things like "perl -spi -e '<script>' <files>"
> > to use whatever comes out of the current "sed -[Ii]" discussion
> > instead.
>
> Why?? If someone wants to use perl in building a port, let them.
> Add a BUILD_DEPENDS.
Seems like an awful amount of installation if all you are going to be
doing with it is something that can be easily acheived by sed (which is
probably the biggest case).
It's like having your port depend on teTex just to install extra
documentation. It's a overkill for a small gain.
-gordon
John Baldwin
On 09-May-2002 Miguel Mendez wrote:
> On Thu, May 09, 2002 at 08:59:00AM -0700, David O'Brien wrote:
>
>
>> > A symlink is a much more sensible solution to this problem and a
>> > redirector just seems to be creating a toy for the fun of it rather than
>> > to solve any real problem.
>>
>> A symlink to where?? You may not assume /usr/local.
>
> IMHO the symlink should only be created by the perl port install, so
> ${PREFIX}
> is honoured.
Ports should avoid messing with stuff outside of ${PREFIX} if they can
help it. Existing systems will already have a /usr/bin/perl on them
unless the user goes and removes it. People writing or executing scripts for
new systems can easily figure out something is wrong when they get:
/usr/bin/perl: not found
or some such. Just remove perl and let it be installed from the port.
As long as its documented in the release notes and UPDATING I don't think
this is a major concern.
--
John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majo...@FreeBSD.org
Patrick Gardella
base install. It just won't be built with world. The thought is to install it as a port (pkg_add)
at install time. They would have to go out of their way to *not* install it. The sysadmin can do
something like this if they don't want Perl installed at all.
Patrick
On Thu, 9 May 2002 08:24:57 -0700 (PDT)
"Joseph Scott" <jos...@randomnetworks.com> wrote:
>
> This may sound like an extremely silly little idea, but is there
> any reason why we can't just replace /usr/bin/perl with a shell script
> that prints out something like :
>
> Perl is no longer comes with the base install of FreeBSD, please install
> it from your ports collection, in /usr/ports/lang/perl5.
Terry Lambert
> On Thu, 9 May 2002, Mark Murray wrote:
> > > Can somebody, or maybe you, make a list off the perl script in the base
> > > OS, that need to be rewritten??
> >
> > Of course! :). Done, sent to current@
>
> Perfect...
>
> What is preffered: C, Shell ???
Uh, csh. Preferrably with tcsh extensions, so it won't run anywhere
else. In a pinch, I guess you could use "bash".
<cackles maniacally, and ducks>
-- Terry
Miguel Mendez
Hi,
> Ports should avoid messing with stuff outside of ${PREFIX} if they can
> help it. Existing systems will already have a /usr/bin/perl on them
> unless the user goes and removes it. People writing or executing scripts for
> new systems can easily figure out something is wrong when they get:
Now that I think of it, you are absolutely right, John. Just let's make
a big big banner saying "Perl is no longer in base" so everybody notices
:)
Richard Arends
> Uh, csh. Preferrably with tcsh extensions, so it won't run anywhere
> else. In a pinch, I guess you could use "bash".
As far i can see, (almost?) everything is already moved from perl to
something else. Asked it, went away for a few hours and all the work is
done :-)
Greetings,
Richard.
----
An OS is like swiss cheese, the bigger it is, the more holes you get!
David O'Brien
> > Ports should avoid messing with stuff outside of ${PREFIX} if they can
> > help it. Existing systems will already have a /usr/bin/perl on them
> > unless the user goes and removes it. People writing or executing scripts for
> > new systems can easily figure out something is wrong when they get:
>
> Now that I think of it, you are absolutely right, John. Just let's make
> a big big banner saying "Perl is no longer in base" so everybody notices
Ok, then. What is so wrong with /usr/bin/perl being "/usr/bin/env perl",
or DES's wrapper?
David O'Brien
On Thu, May 09, 2002 at 09:32:10AM -0700, Gordon Tetlow wrote:
> > Why?? If someone wants to use perl in building a port, let them.
> > Add a BUILD_DEPENDS.
>
> Seems like an awful amount of installation if all you are going to be
> doing with it is something that can be easily acheived by sed (which is
> probably the biggest case).
Please don't be telling a maintainer how to do his job. If you want to
push a direction of a port, become its maintainer.
(I dare say even 90% of Perl haters will have it installed anyway, so
using is not such a big deal)
Dag-Erling Smorgrav
> Ok, then. What is so wrong with /usr/bin/perl being "/usr/bin/env perl",
> or DES's wrapper?
People just need something to be righteously wroth about. Moving perl
out of the base is no longer open to debate, so they've found another
bikeshed to argue about.
Please stop this thread.
DES
--
Dag-Erling Smorgrav - d...@ofug.org
To Unsubscribe: send mail to majo...@FreeBSD.org
Jordan DeLong
>
> On Thu, 09 May 2002 08:24:57 MST, Joseph Scott wrote:
>
> > This may sound like an extremely silly little idea, but is there
> > any reason why we can't just replace /usr/bin/perl with a shell script
> > that prints out something like :
> >
> > Perl is no longer comes with the base install of FreeBSD, please install
> > it from your ports collection, in /usr/ports/lang/perl5.
>
> We don't want the port to overwrite a script that exists in userland,
> and we don't want installworld blowing away (or, even worse, following)
> the port's symlink.
>
> Symlink or redirector, but please not this. :-)
Shouldn't ports *not* touch anything outside of ${PREFIX}? I, for
one, can't stand when ports do that (except /etc/shells -- that's
different).
Seems that neither symlink nor redirector is neccesary; portable
perl shebangs use #!/usr/bin/env perl to search $PATH for it, and
if the local sysadmin wants they can make a symlink.
--
Jordan DeLong
frac...@allusion.net
Dag-Erling Smorgrav
> Seems that neither symlink nor redirector is neccesary; portable
> perl shebangs use #!/usr/bin/env perl to search $PATH for it, and
> if the local sysadmin wants they can make a symlink.
Most Perl scripts use '#!/usr/bin/perl'; also, using a redirector has
the very nice side effect of clobbering the old Perl binary.
Garance A Drosihn
> > Symlink or redirector, but please not this. :-)
>
>Shouldn't ports *not* touch anything outside of ${PREFIX}?
>I, for one, can't stand when ports do that
>(except /etc/shells -- that's different).
I agree. That's why a redirector makes more sense, because
the redirector can be part of the base-system, and the port
can be installed in /usr/local.
>Seems that neither symlink nor redirector is neccesary;
>portable perl shebangs use #!/usr/bin/env perl to search
>$PATH for it, and if the local sysadmin wants they can
>make a symlink.
Many many perl scripts already exist which do not do this.
Yes, we now know that it would be more portable to write
a script that way, but that doesn't magically change all
the scripts which are already written and which are very
used to assuming that perl is at /usr/bin/perl.
Also, the /usr/bin/env approach means that scripts are
now subject to the setting of $PATH, and that is not
necessarily a good thing. Remember that the person
running the script is not necessarily the person who
wrote it, and is not necessarily aware that it even
is a perl script, or that PATH is important when
running that script. (PATH would not be important
for a script which is using /usr/bin/perl)
--
Garance Alistair Drosehn = g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
Sheldon Hearn
On Thu, 09 May 2002 10:13:04 MST, Terry Lambert wrote:
> Uh, csh. Preferrably with tcsh extensions, so it won't run anywhere
> else. In a pinch, I guess you could use "bash".
>
> <cackles maniacally, and ducks>
Poul-Henning was too kind. You shouldn't be banned from the lists, you
should be taken out back and shot until dead. :-)
Ciao,
Sheldon.
Lyndon Nerenberg
Garance> I agree. That's why a redirector makes more sense, because
Garance> the redirector can be part of the base-system, and the port
Garance> can be installed in /usr/local.
There is one problem with the /usr/bin/perl redirector: it can cause
autoconfiguration scripts to mistakenly think perl is installed on the
system (they find the /usr/bin/perl wrapper) when it isn't (there is no
perl-from-ports backing the redirector).
--lyndon
Jonathan Perkin
> There is one problem with the /usr/bin/perl redirector: it can
> cause autoconfiguration scripts to mistakenly think perl is
> installed on the system (they find the /usr/bin/perl wrapper) when
> it isn't (there is no perl-from-ports backing the redirector).
An auto-configuration script which merely checks for the existance
of a file rather than actually testing it's the file it needs is a
bit silly and probably deserves the breakage.
--
Jonathan Perkin - BBC Internet Services - http://support.bbc.co.uk/
Please check email headers for complete list of contact details
Lyndon Nerenberg
Jonathan> An auto-configuration script which merely checks for the
Jonathan> existance of a file rather than actually testing it's the
Jonathan> file it needs is a bit silly and probably deserves the
Jonathan> breakage.
And just what else besides Perl would you expect to find in
/usr/bin/perl you silly pedant?!? ;-)
David W. Chapman Jr.
> >>>>> "Jonathan" == Jonathan Perkin <ske...@rd.bbc.co.uk> writes:
>
> Jonathan> An auto-configuration script which merely checks for the
> Jonathan> existance of a file rather than actually testing it's the
> Jonathan> file it needs is a bit silly and probably deserves the
> Jonathan> breakage.
>
> And just what else besides Perl would you expect to find in
> /usr/bin/perl you silly pedant?!? ;-)
A perl wrapper?
--
David W. Chapman Jr.
dw...@inethouston.net Raintree Network Services, Inc. <www.inethouston.net>
dw...@freebsd.org FreeBSD Committer <www.FreeBSD.org>
Brooks Davis
>
> Jonathan> An auto-configuration script which merely checks for the
> Jonathan> existance of a file rather than actually testing it's the
> Jonathan> file it needs is a bit silly and probably deserves the
> Jonathan> breakage.
>
> And just what else besides Perl would you expect to find in
> /usr/bin/perl you silly pedant?!? ;-)
A broken symlink? Perl 4? Perl 6? A perfectly reasionable wrapper
script? If these programs detect perl and don't work because the
wrapper is there, then a) they are broken and b) it will only take a
couple minutes to fix by adding a perl package so why worry.
/usr/bin/perl should work if perl is installed to avoid a massive POLA
violation. Since ports must not touch /usr/bin and we must not assume
that PREFIX=/usr/local, a symlink is out of the question. A wrapper
isn't really going to cost us anything performance wise and allows the
possability of providing something more useful then "File not found"
as an error message. As such, it's a very good solution.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
Terry Lambert
> On Mon May 13, 2002 at 02:02:28PM -0600, Lyndon Nerenberg wrote:
> > There is one problem with the /usr/bin/perl redirector: it can
> > cause autoconfiguration scripts to mistakenly think perl is
> > installed on the system (they find the /usr/bin/perl wrapper) when
> > it isn't (there is no perl-from-ports backing the redirector).
>
> An auto-configuration script which merely checks for the existance
> of a file rather than actually testing it's the file it needs is a
> bit silly and probably deserves the breakage.
FWIW: All the ones I have lying around that care about perl try to
get the version by running it.
-- Terry
Lamont Granquist
On Mon, 13 May 2002, Jonathan Perkin wrote:
> On Mon May 13, 2002 at 02:02:28PM -0600, Lyndon Nerenberg wrote:
> > There is one problem with the /usr/bin/perl redirector: it can
> > cause autoconfiguration scripts to mistakenly think perl is
> > installed on the system (they find the /usr/bin/perl wrapper) when
> > it isn't (there is no perl-from-ports backing the redirector).
>
> An auto-configuration script which merely checks for the existance
> of a file rather than actually testing it's the file it needs is a
> bit silly and probably deserves the breakage.
There's two sides to this. One side is that you should always adhere to
the FreeBSD filesystem standard. The other side is that if /usr/bin/perl
exists it should always be a working perl program. I'd like to throw out
a mention that I think that all filesystem standards imposed by the
people writing the OS or the software packages and not imposed by the
system administrators is the wrong way to go.
A somewhat rambling stream-of-consciousness argument that I wrote about
this is here: http://www.scriptkiddie.org/rants/registry.html
I've been thinking that an interesting project would be to implement the
"simple" part of this with the hooks into autoconf and /usr/bin/install
and convert the FreeBSD base OS to use it. I'll be doing that after
someone can roll the clock back to 1999 and have my stock options hit
200 though...