Re: Another question re: 2.0

[Chris Travers <..hidden..>]

On Wed, Mar 17, 2010 at 12:06 PM, Adam Thompson <..hidden..> wrote:
>> From: Ian Goodacre [mailto:..hidden..]
>>
>> Is there a problem with current distribution methods?
>
> Yes.
>
> Somewhere north of 80% of potential users will not install software if it
> isn't available in either their distribution's repository (ports tree,
> apt/yum/that-thing-SLES-uses, portage, etc.) or at least in their
> distribution's "native" format (i.e. RPM).
> Even integrators and consultants (like myself) vastly prefer to install
> software from some sort of centralized repository - of which CPAN is a
> perfectly good example - rather than downloading and installing from
> tarball.

I am going to chime in here with a couple points.

I think there are a couple things to be gained by moving towards CPAN.
  These include:

1)  Better exposure
2)  Easier handling of dependencies
3)  A possibility for a partial installation for other uses (portions
of our logic that other apps may want to use would be broken off and
installed as separate modules).  This might help get more
contributors.  The "project" could essentially divest itself from a
lot of common infrastructure tasks (Authentication and template
handling for example)  and instead spinoff a series of other projects
with a common core committee (at least to start with).
4)  Bundles could be defined for various markets as well (more on this below).

It might also allow us to push harder to get the base modules
distributed in mainstream distributions' repos.

> Everything about LedgerSMB can be wrapped in a Perl "Bundle" without too
> much trouble - even the templates can be treated as auxiliary files, there
> are quite a few CPAN modules that do that already - and the installation
> routines for CPAN bundles have fairly-well-established idioms for
> interactive prompting (viz. Bundle::CPAN installation, in fact!) I don't
> see any reason why CPAN wouldn't work.

Bundles could also be defined for various markets as well.
>
> Then there's the downstream benefits: rewrapping a CPAN bundle as a
> distribution-specific package isn't always trivial, but it's such a common
> task that there are reasonably-well-documented tools and techniques for
> doing so.  This potentially eliminates much of the heavy lifting a
> distribution packager would have to do otherwise, esp. WRT prompting for
> information during interactive installation and building a file manifest.

I don't see the tarballs as going away either.  CPAN would become one
more target for distribution.  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).

> There's something to be said for the good ol' tarball.  But in a world
> where software management is an increasingly important part of any system,
> what is usually said... amounts to "Yuck".  (Or in today's lingo, "oh man,
> you've gotta be kidding, no way, that's so Old School" - quoting a former
> employee, on the subject of manually installing from a tarball.)

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.

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

Best Wishes,
Chris Travers