Introduction of overlapping postfix26 package in EPEL-5?

[Robert Scheck]

Hello folks,

I would like to see a newer version of the "postfix" package in EPEL-5,
because the Postfix 2.3 as shipped with RHEL 5 is pretty old. Postfix 2.3
is even known to cause trouble when setting up e-mail distribution lists
via Active Directory in a specific combination.

In order to satisfy my needs, I've build a "postfix26" package. And please
note, that it's not "postfix-2.6.x", but "postfix26". So it equals to what
Red Hat did with "samba" vs "samba3x", "php" vs "php53" or "postgresql" vs.
"postgresql84". My package is not upgrading a regular postfix installation.

But my package is overlapping with the regular postfix package from RHEL 5,
e.g. both provide and use /etc/postfix or /var/spool/postfix - and provide
/usr/sbin/postsuper or /usr/sbin/postconf. In the end that means that you
can not install both packages at the same time, they are conflicting with
each other.

Technically it should be possible to make the "postfix26" package somehow
in parallel installable, but that requires a) patching postfix, b) lots and
lots of testing and c) SELinux adaptions - a huge effort for less result.

I know the "Philosophy of EPEL" says "to never replace or interfere with
packages shipped by Enterprise Linux", but why should we have more strong
rules than Red Hat has? Let us look to python in EPEL-5: We're shipping
python26* packages - isn't this a "replace packages shipped by Enterprise
Linux" somehow?

Coming back from theory to reality: If you install a postgresql84, do you
really want to install an old postgresql 8.1 in parallel? No, you don't
want to do this, because 8.4 is much better. Why would somebody want to run
a very old postfix 2.3 in parallel with a postfix26? It makes same less
sense to run two different PostgreSQL versions as it does for Postfix. If
you decide to explicitly use the newer versions by switching manually, why
do we need to take care for parallel installation? Even if you additionally
install postfix26, you're on your own, because Red Hat won't support this
new package, but only the original postfix one. What's the real benefit of
parallel package installations in cases like this?

I'm mentioning this, because some people dislike the idea to do the same in
EPEL what Red Hat already did for RHEL. Shouldn't we think about what makes
sense rather just trying to follow old rules from former times?

Unfortunately the IRC meeting today was not helpful nor does EPEL have some
kind of a Steering Commitee that could vote on this somehow. How to get a
decision for such things? Doing a voting on the mailing list? If there is
no chance for postfix26 as it's packaged now in EPEL, I would like to see
some kind of a real result not just pointing to our old rules that were in
parts done by people who are maybe no longer contributing to EPEL at all...

Ideas? Comments? Recommendations? Suggestions? Votings?


Greetings,
  Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20110419/4e430a61/attachment.sig>