List for people interesting in developping and using Sympa packages

[Daniel MAHER <address@concealed>]

On 05/11/2010 11:54 AM, David Verdin wrote:

> > Moving into more subjective territory, it's been my experience that,
> > at the end of the day, option #2 is the easiest to maintain from a
> > packaging perspective. With specific regards to an RHEL/CentOS RPM,
> > however, there remains the problem of the poor decision of the distro
> > maintainers to NOT modularise their Perl packages internally - this is
> > the root of the problem, really.
> What do you mean? On CentOS your only option to install CAPN modules is
> the CPAN shell?

There are two ways : The CPAN shell, or via RPM, but neither is perfect.

The CPAN shell, while useful, side-steps the whole RPM package 
management process.  In many environments this is an unacceptable 
behaviour, not only because it makes enterprise standardisation very 
difficult (at best), but also because the CPAN modules may conflict with 
upstream packages.

The upstream packages (RPM) come from a variety of sources, including 
the RHEL / CentOS repositories, but also sites like Dag, RPMForge, 
Magnum Solutions, and so forth.  The problem with this path is (sadly) a 
function of the RHEL / CentOS approach to packaging Perl : they don't do 
it cleanly.  In a nutshell, they include a bunch of CPAN modules 
(CGI.pm, for example) directly in thier Perl RPM.  This is handy in that 
it means the admin / user only needs to install one RPM and they get a 
bunch of functionality, but it also means that upgrading unique modules 
will cause conflict problems with the base Perl RPM.

As i said, neither solution is perfect. :(

> Could it be something like "sympa-libs" ?

Yes, it certainly could be ; from a naming perspective that would make 
it in line with other software packages out there today.  That said, it 
might be a little misleading, in that it would theoretically contain 
Perl modules that, to be fair, are NOT Sympa-specific.  Also, i submit 
that the name « sympa-libs » implies that the Sympa team is responsible 
for the contents - this would not fundamentally be the case, as only the 
packaging would be managed by the Sympa team.

> That's why I created a list dedicated to Sympa packaging:
> https://listes.cru.fr/sympa/info/sympa-packagers.

Good call.


--
Daniel MAHER <dma PLUS sympa AT witbe DOT net>