List for people interesting in developping and using Sympa packages

[Daniel MAHER <address@concealed>]

On 05/11/2010 12:07 PM, Victoriano Giralt wrote:

> | That said, there is a middle-path : make available separate modified
> | CPAN RPM packages that satisfy the requirements. These packages, which
> | are not that hard to build, would live outside of the main Sympa RPM,
> | and would not be officially supported. In order to avoid conflicts,
> | they would have different names (*-sympa- ?), and they would install
> | into either site_perl or some other Sympa-specific location as
> appropriate.
> But then, we risk having several copies of the same thing that could break
> other parts of the system, wouldn't we?

Yes, if you auto-build the CPAN modules as RPMs (which, btw, is 
generally how it works in CPAN / RPM repos).  Instead, for the 
relatively small number of conflicting packages (CGI.pm is a notable 
example), the spec files can be edited to ensure that they install to a 
standard non-colliding spot.  See below...

> | This would remove the onus of maintenance from the Sympa team while
> | still providing the necessary support for the « broken » distributions
> | to those who are unable to build the packages themselves for whatever
> | reason. Given that there are only a handful of legitimate conflicts,
> | this might not be a bad option. As well, if the modularisation issue is
> | addressed in 5.5+, then eventually the unsupported packages would become
> | less and less important (and could be phased out).
> I see another option: suggesting the use of already good and responsive
> repositories for Perl packages that adhere to the "sensible way" of doing
> things, like Magnus. I've contacted the maintainer and he is a quite nice
> guy. I think I was able to circumvent the "Perl problem" somehow (I do not
> have access to my system administration blog right now).

I'm not familiar with Magnus, but i am familiar with Magnum (perhaps 
that's what you meant?).  I've spoken with the admin there about this 
topic, and he doesn't have a standard solution for the stock RHEL RPM 
collision problem either.  It is perhaps worth noting that his RPMs are 
auto-built using cpanspec, and thus are susceptible to the same problems.

Last month i wrote a reasonably lengthy article on this topic, as well 
as what i think is an acceptable solution, on my blog here :

http://www.dark.ca/2010/04/08/cpan-rpms-in-rhel-centos/

In summary, i propose using cpanspec to generate the baseline spec 
files, then editing them by hand to change the installation target to 
the Perl site directory (instead of base or vendor).

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