List for people interesting in developping and using Sympa packages

[Daniel MAHER <address@concealed>]

Continuing the repost...

On 05/11/2010 02:00 PM, Daniel MAHER wrote:

> -------- Original Message --------
> Subject: Re: [suggest] Sympa and dependencies
> Date: Mon, 10 May 2010 15:36:15 -0400
> From: Dan Pritts <address@concealed>
> To: IKEDA Soji <address@concealed>
> CC: Daniel Maher <address@concealed>, Dan Pritts
> <address@concealed>, Victoriano Giralt <address@concealed>, David
> Verdin <address@concealed>, Matt Messana <address@concealed>
>
> Hello Soji,
>
> I saw your post on the RPMforge list.
>
> It looks like you rolled an updated CGI.pm and other perl modules that
> conflict with the RHEL perl directly into the RPM?
>
> I have cc'd several others who have been working and/or talking about
> RPM'ing sympa.
>
> (for the rest of you let me introduce Matt Messana, address@concealed,
> who i discussed this with briefly)

Hi all,

I hate to sound like a broken record here, but there are really only two 
ways to properly put together an eventual Sympa RPM package :

1. All necessary requirements built-in and in totally separate directory 
structures (with appropriate modifications to Sympa's @INC).
2. None of the requirements built-in, with appropriate facility to allow 
the admin to specify the include paths.

Going half-way is a recipe for disaster, as is including modules that 
conflict with system (read : distro) defaults.  This is generally true 
for any software package - not just Sympa.

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.

While the problem may or may not be addressed in the upcoming 5.5 
release (i haven't had time to check yet, ditto for the RHEL 6 beta), 
the best response is to stick with option #2, and then trust that the 
administrator can do what's necessary to get things installed properly. 
 If - and this is a big if - the Sympa team wants to become responsible 
for maintaining downstream CPAM module packaging and RHEL / CentOS 
conflicts, then that's their call... i wouldn't do it.

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.

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).

Just my 2 centimes.


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