On Tue, Mar 28, 2000 at 02:47:15PM -0800, Joey Hess wrote: > Chip Salzenberg wrote: > > Since we're just a few people and Debian users are a multitude, I > > think we should build them both. > > Hm, the perl-thread package in debian is clearly marked as experimental, > and nothing at all depends on it. All users of the package would thus be local > users. Since installing the perl 5.6.0 packages would not cause that package > to be removed or stop working anyway, I don't think local scripts that use the > old thread model will be broken either. So I don't see a great need to include > both.
Yeah. Do we really want to let perl proliferate packages much further? > > Q: How about a shared libperl? Cons: It would require the libperl.so > > to be on the boot floppy, and it would impose a performance penalty > > of, what, 10% or so? Pros: It would allow mod_perl, vim, and other > > tools that use Perl to use libperl.so, cutting total disk usage. > > I thought last time this came up there was a decision to make a libperl, > just not link /usr/bin/perl itself to it. So there would be some > duplication, but less than there is now, and this would be a bit smaller. > > -rwxr-xr-x 1 root root 1274960 Mar 26 09:08 /usr/bin/vim* > > I don't care if perl is 10% slower whewn I run it inside vim. I _do_ care > if my cgi script on my production webserver slows down by 10%. But if you run a production webserver with mod_perl... I think the book is still open on using a shared libperl on an intel webserver. On less register starved architectures, of course, it is much less of an issue. Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \--------------------------------/ \--------------------------------/
