For the record, you will hear no disagreement from me. I recognize that
this is a HARD problem. Nonetheless, I think it's an important one, and
solving it (even imperfectly, by only supporting well-defined platforms)
would be a major coup.
--Josh
At 23:31 on 06/05/2002 BST, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> 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/
