List for people interesting in developping and using Sympa packages

["Stefan Hornburg (Racke)" <address@concealed>]

On 05/11/2010 03:01 PM, Daniel MAHER wrote:
> 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.

I agree, RedHat definitely doesn't do a good job on packaging Perl and
its modules. Debian is way better in this regard.

Regards
        Racke

--
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team