At 12:48 PM +0200 6/9/02, Anton Berezin wrote:
>On Sat, Jun 08, 2002 at 02:14:09PM -0400, Trish Lynch wrote:
> > Anton, if you don;t get around to it this weekend, mind
> > if I take a stab at it?
>No, I don't mind at all. If only we can agree who does what. :-(
RPI has been running with something like the perl wrapper on our
systems for many years. It can be very useful, if it's done
right. My fear is that everyone is hoping for some quick fix
(something as quick as creating a symlink), and does not want
to really think about what we want from this wrapper.
I would argue we need to stop a minute and think of what we're
doing, why we're doing it, and what result we want. We don't
have to paint a lot of bikesheds, but we should think it
through a bit more than we have so far.
We (developers) have decided to make the incompatible system
change of removing perl from the base system (a change that I
completely agree with). This is an incompatible change, no
matter how much we try to lessen the disruption from it. If
we want to make this incompatible change on relatively short
notice, then we must have a wrapper in /usr/bin/perl which
works exactly as /usr/bin/perl worked when it was part of the
We do not want a solution that starts out "users will just have
to edit all the perl scripts they've ever done, and change...".
That is not user-friendly. We (developers) are making this
change, it is our responsibility to make it go smoothly.
The perl wrapper should not depend on the setting of PATH. When
perl was part of the base OS, then what you got by specifying
/usr/bin/perl did not depend on the setting of PATH. The new
wrapper should not. We do not know all the environments that
all the user-written perl scripts will be running in.
I do completely agree that it would be very useful if whatever
we did for a wrapper did make it easier to have multiple
versions of perl available. In fact, at RPI this is the *main*
reason we have a wrapper for perl (and for several other
I have thoughts on how that version-selection could work, but
that debate can wait. The main point I want to make right
now is that the initial version of the wrapper should not
depend on PATH. It should "just work" when the port is
installed, and work in all situations. If 'use.perl port'
is required for the wrapper to work in all situations, then
the wrapper should say 'Run use.perl port' in addition to
saying 'pkg_add -r perl'. I think it would be better if
the use.perl step was not required, although obviously that
script does need to be smarter in case someone does run it.
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute or [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message