Developers of Sympa

[Emanuele Zeppieri <address@concealed>]

David Verdin wrote:

> Hi,
>
> Yes, CPAN is clearly a big flaw in the Sympa installation process. I 
> don't want to think about how many potential users can have turned down 
> from Sympa due to repeated CPAN module installation failure...
> We seriously consider finding a solution to remove this limitation. 
> Actually, we heard that it is possible to create packages off CPAN. 
> We'll have a look at it as soon as things have calmed down for the Sympa 6.
>
> One of the two-three main development tasks coming for Sympa is: "Make 
> the installation process easier".
> This includes resolving the CPAN problem, and also improve the wizard, 
> which would probably imply that most of the Sympa configuration would be 
> done and modified through the web interface.
>
> Any thoughts / tips about these aims?

As Lyle said, simply distribute all the needed CPAN modules inside an 
arch specific Sympa tarball (possibly including even perl itself), and 
install said modules (and possibly perl) in a private sympa dir.
(No PAR needed: with a package as large as Sympa, it would probably only 
complicate things).

Having said that, the sympa installation process is not a problem at all 
on any OS with a serious package manager (such as debian), since such OS 
would distribute sympa ad all and every CPAN module it depends upon, 
precompiled, through its package manager.

Here's is for example the Sympa debian package:
http://packages.debian.org/sid/sympa

just run:
apt-get install sympa

and you will have it downloaded and installed even with apache+fastcgi, 
soap, mysql and the mail server automatically configured for you.

So in this case it's CentOS to blame, not sympa nor CPAN (I'm very 
susrprised anyway that there is not an already packaged rpm for Sympa!)

Thus at the end you will have to distribute (at least) two sympa 
tarballs: a /bare/ one (like the current one) for the experienced users 
and/or to facilitate the task of the debian (and other serious OSes) 
maintainers, and a /full/ one, for the inexperienced users and/or for 
flaky OSes.
Furthermore, the full one must be architecture specific, so you will 
have many of them.

Here is an example of an (great) application (called POPFile) which 
adopts perfectly such a strategy.
The Windows installer for example includes all the needed CPAN modules, 
a perl-based http-server and even perl itself, so that the installation 
it's just a matter of a double-click, even if you don't have perl 
installed on your system (the inexperienced users simply will never know 
that the application runs on perl). And if the user already has perl 
installed, it will only be a matter of few KB duplication with no 
interference at all with the /main/ perl:
http://getpopfile.org/download

Thank you for the great work with Sympa!
-Emanuele