On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote: > > Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See > also debian's apt-get. > > Which brings me to my pet peeve- I think it's time to start doing binary > packaging in CPAN, for those who don't want to bother with compilation. > > That has interesting implications for how we deal with paths, but still, I > think it's worthwhile. > > Of course you would want to support source as well, but having binary > available for those who want it just seems like a darn good idea.
OK. Say I want binaries for my 3 boxes: On Bagpuss /usr/local/bin/perl -v says: This is perl, v5.8.0 built for armv4l-linux (with 1 registered patch, see perl -V for more detail) but you had better actually build that with -v3 flags on your ARM compiler because my machine's hardware can't cope with the v4 instructions on the CPU On Thinking-Cap /usr/local/bin/perl -v says: This is perl, version 5.004_05 built for i386-freebsd Copyright 1987-1998, Larry Wall 5.004 is officially still supported, and some modules do build on 5.004 [Third box, Marvellous-Mechanical-Mouse-Organ is an SGI Indy and doesn't doesn't want to power up for some reason, probably because it's been off for about 12 months] I presume you're going to suggest that they are too obscure for binary CPAN to support them. So limit things to the most recent perl. But having experimented with trying to ship 5.8.0-RC1 between FreeBSD versions, there are sufficient changes between libc on 4.4 STABLE and 4.5 STABLE such that you can't run a binary compiled on 4.5 on a 4.4 box due to missing symbols. So you're starting to enter version compatibility nightmare. And if you have module needing a C++ compiler, are you going to ship your x86 linux binaries using RedHat's 2.96, or a real gcc? And are you doing dependencies, or are you interfacing with the OS package manager? And if you're not interfacing, but you are adding modules to the OS perl, then what do you do if one of your dependency modules is already there? Do you just go "oh good", have binary CPAN say nothing, and then hope that the OS packaging system doesn't remove the dependency module from under you? I believe that binary CPAN would have problems that scale as the number of OS subversions that binary CPAN would try to support. This may sound rather negative, but it basically means that I'm feeling sufficiently pessimistic that I don't think there are reasonable solutions to the problems. However, that's only my opinion, and others' will differ. On the other hand, I think the idea of multiple platforms automatic CPAN testing is a very good idea. Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
