Date: Thu, 24 Oct 1996 10:19:33 -0700 (PDT) From: Dmitry Kohmanyuk <dk@dog.farm.org> To: adam@veda.is (Adam David) Cc: freebsd-hackers@freebsd.org Subject: Re: ex/vi version 1.79 now available for anonymous ftp. Message-ID: <199610241719.KAA14773@dog.farm.org>
next in thread | raw e-mail | index | archive | help
In article <199610241232.MAA26317@veda.is> you wrote: > > > Two direct consequences: > > > > > > 1. Perl 5.003_smth goes from ports to main tree -- > > > packed as a big shared library, + a 8k /usr/bin/perl; > > > and /usr/bin/vi and all other programs using Perl5's > > > embedded features will use that shared lib. hmm, shared library, yes... main tree - not sure... maybe /usr/contrib. It is really a problem w/whole BSD tree - as much as individual programs started from BSD codebase (or later included into FreeBSD one) continue to develop, it would be a continuing problem of base tree/contrib tree/port distinction. Although Perl4 have been brought into the base tree (usr.bin), it now seems natural to replace it with Perl5 - still it can be better to not continue to do this as a base tree component. Now think about nvi or other `basic' utility: the fine line between base tree and ports collection means `would be installed by default / is an option' and so `is already present / can be missing', then `is necessary / is optional'. We want for nvi/perl/tk to always be present and we know that some ports can be not installed => we move them into main tree (whenever usr.bin or contrib, doesn't matter much). Now, how about some ports to be _unconditianally_ installed?? (like lynx, and then, nvi and perl5, if these are about to become a ports)? zlib comes next to mind, and there are probably others (gcc?) The problem with tree->ports migration is that a base tree framework is much more suited to interconnected utilities and is better integrated into make world process (bootstrapping tools). Still, for some programs which don't need it (like nvi), moving to ports can be a good idea. > > I think we were waiting for Perl5 to shake out, and with good reason. > > Many parts of the PERL programming world still had yet to shift > > themselves, which was another good reason to stick with Perl4. > Isn't there a perl4 compatibility module or something, that would ease the > transition? The Perl5 is compatible enough to run _most_ of Perl4 code. That Perl4 code which is _not_ compatible with it usually depends on some undocumented or deprecated (read: obscure) features. > > Nowdays, I don't know. First off, how much bigger is it going to > > make our default source tree and second, is the perl world really > > ready for /usr/bin/perl to be perl5 by default? Perl4 is no longer supported by its author. Nobody seems to offer support. The mindshift is done anyway. > In the worst case... how about /usr/bin/operl for the exceptions, and nuke > it later? /usr/bin/perl4 should be pretty obvious name. I also vote for /stand/perl (statically linked) to be a last-resort replacement for /bin/cp, /bin/mv, and many more things ;-) Just my $.02 (being in the U.S., I now feel free use this expression ;-)) -- No matter how subtle the wizard, a knife in the shoulder blades will seriously cramp his style.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610241719.KAA14773>