Re: Another question re: 2.0

["Adam Thompson" <..hidden..>]

> I don't see the tarballs as going away either.

Well, no.  But CPAN is also a distribution mechanism for tarballs; from 
what I've seen (granted, I've never written a CPAN module) it looks like 
you can either target CPAN primarily and spin off tarballs from that, or 
structure your project so it's easy to wrap using the CPAN tools but treat 
tarballs as primary.  Either-or, it seems to be developer's choice... 
especially since internally, all CPAN does is download a tarball that 
conforms to certain conventions and do things to the contents that are 
defined by certain conventions.  Of course, you could say much the same 
thing about RPMs and DEBs, which are both tarball-in-tarball formats.

> There are many cases where installing a tarball is a good way to go (we 
> have them signed, for example, and I[]  don't see a CPAN solution for 
> that).

I don't know how it's done, but CPAN does support that.  At least, it 
supports basic integrity checking - as evidenced by the fact that CPAN 
complains mightily if it doesn't have access to the various Hash:: 
modules.  I believe "signing" (by hashes, not by X.509 certs or anything 
like that) is accomplished out-of-band.


> There are a lot of software projects I usually install from tarball
> (PostgreSQL is one) and compile from scratch.  Installing from a
> tarball usually gives you a much finer level of control over the
> installation.

As a Gentoo user, I obviously don't have a religious problem with 
compiling software ;-)

But using prepackaged software (whether by CPAN, RPM, Ports tree, 
whatever) frees me from dealing with the minutiae of tracking what I 
deployed on which system with what options, and particularly from going 
'round and rebuilding multiple systems.  As long as I've only had to do a 
custom deployment of any given software (SAMBA comes to mind...) for one 
customer, or maybe two, I can handle it but if I have to do anything more 
strenuous than "yup update; yum upgrade" or its equivalent, it's all too 
easy to make mistakes and accidentally leave some important option out for 
customer X, particularly when customers A-Y and Z don't want that option 
but X does.

Been there, done that, shut down an entire city's infrastructure for a day 
by accident...

> So I don't see this as "either/or" but rather as a way of reaching
> more users.

Regardless of how you get there, mass distribution imposes certain 
features on software.  Regardless of whether you planned to go there or 
not, you wind up tailoring your development approach to make it easy to 
deploy across the smallish number of very-common distribution channels 
(e.g. Fedora & Ubuntu repositories, among others) merely to avoid drowning 
in details.

In the end, reaching more users benefits (almost) everyone no matter how 
it happens.

-Adam Thompson
 ..hidden..
 (204) 291-7950