List for people interesting in developping and using Sympa packages

[Daniel MAHER <address@concealed>]

continuing the repost..

-------- Original Message --------
Subject: Re: [suggest] Sympa and dependencies
Date: Tue, 11 May 2010 11:54:49 +0200
From: David Verdin

Hi,

Le 11/05/2010 11:32, Daniel Maher a écrit :
> On 05/10/2010 09:36 PM, Dan Pritts wrote:
>
> > 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)
> >
> > I will take a look at your SRPM.
>
> > On Sun, May 09, 2010 at 03:13:56PM +0900, IKEDA Soji wrote:
> > > Hi,
> > >
> > > Would you like to add package of Sympa mailing list server to RPMforge?
> > >
> > > Spec-files are attached (some are copied from Mandriva and old Fedora).
> > >
> > > Full SRPM I built for RHEL5/CentOS5 is here:
> > >
> > > http://sympa-ja.org/download/redhat/SRPMS/sympa-6.0.1-0.20100509.RHEL5.src.rpm
>
> 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.
What do you mean? On CentOS your only option to install CAPN modules is
the CPAN shell?
> 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.
We're not sure we want to, neither. If we invest in the modules problem,
that would probably be in an agnostic way regarding distros, ie a CPAN
bundle or any wsay to ease the install from the source. We still did not
rule out the "distribute the modules with the code" option, but we feel
it could be a pain, so we wait for a calmer development period to
investigate deeper.
> 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.
Could it be something like "sympa-libs" ?
> 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.
For you, I have 5. ;)
Anyway, as Is see more and more people charing thoughts about creation
and maintainance of a Sympa RPM, I thought it would be a good idea to
gather them and, if possible, make them available for a larger number of
people. This could be a good thing for Sympa packagers to have a place
to talk and retrieve previous advices and ressources.

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

An engineer at CRU is currently also working on a Sympa RPM. Him and the
Sympa authors are subscribed to this list.
I invite you to subscribe (and maybe repost there some of the messages
you sent to each other until now, so that they are archived) and favour
this channel if you want to share thoughts about Sympa packaging.

I'll advertise about this list on sympa-dev.

Best regards,

David
>

--
David Verdin
Comité réseau des universités

.