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
pgpEXdyfEaDJz.pgp
Description: PGP signature
_______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
