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 12:07:20 +0200
From: Victoriano Giralt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Maher wrote:
| 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 :
You cannot repeat sensible things enough ;) :)

| 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.
Totally agreed.

| 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.
It may be subjective, but it sound like something based on sound
experience. I've been administering systems since 1986 and I have found no
better recipe for disaster and pain than deviating from the norm. This, in
RedHat based systems means installing everything with packages, and then
with the lowest possible friction, this meaning the least possible
interference with the base system. This has even taught me to avoid some
rigid third party drivers for hardware I was using (from big providers)
like entering the gates of Hell.

| 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.
I think that is a good sysadmin's job. Getting everything ready and smooth
for anything that is goung to run on a system.

|  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.
I would advise against that also. There are package maintainers already
time can be better spent doing other things, like improving Sympa ;)

| 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?

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

Another 2 cents :) ;)

- --
Victoriano Giralt
Systems Manager
Central ICT Services
University of Malaga
SPAIN
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFL6SxWV6+mDjj1PTgRAqjzAKCifwWNCFeJH9gRDoUOx3bxWp5S2gCgpCpe
8x0c+lJRVh6bJc/jJmDfCCA=
=sYqo
-----END PGP SIGNATURE-----

.