DragonFly kernel List (threaded) for 2003-08
Re: new sysinstall
0$269$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <slrnbkvm7b.oig.weingart@xxxxxxxxxxxxxxxxxxxxxxx> <20030829184829.2fedd129.cpressey@xxxxxxxxxxxxxxx> <200308300659.h7U6xOM0059135@xxxxxxxxxxxxxxxxxxxx> <3f50871c$0$269$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <3f50ab95$0$269$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <200308302143.h7ULhrtG065363@xxxxxxxxxxxxxxxxxxxx> <3f512938$0$271$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <Xns93E7C3F58A0ACjustinshiningsilence@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Trace: 1062288819 crater_reader.dragonflybsd.org 267 188.8.131.52
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:767
Justin C. Sherrill wrote:
> Purely from a user perspective, I want to note that having to deal with
> a "system perl" vs. a "user perl" on FreeBSD has been an incredible
> annoyance, especially when trying to work with projects that require
> multiple modules and/or particular versions of Perl. I'd like to not
> have that hassle again.
This isn't a problem just on FreeBSD but Solaris as well with the system
perl and you need to install another Perl namespace since from the Perl
programming perspective the system one is outdated.
I think its a mistake having a "system language" like perl in the path
as /usr/bin/perl and it would be better to "hide" the system language
from third party scripts and modules with a name like
/usr/bin/perl5.005__03 and then have the "user language" installed
through ports (or an updated package system).
Although I suppose the best long term solution is different applications
having different views of some sort of virtual filing system.