Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 May 2002 20:33:04 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Mark Murray <mark@grondar.za>
Cc:        current@freebsd.org
Subject:   Re: The future of perl on FreeBSD
Message-ID:  <Pine.NEB.3.96L.1020507202743.83455K-100000@fledge.watson.org>
In-Reply-To: <200205072241.g47Mf0jV002339@grimreaper.grondar.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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
robert@fledge.watson.org      NAI Labs, Safeport Network Services


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020507202743.83455K-100000>