On Tue, 19 Apr 2011, BJ Dierkes wrote:
Let me first introduce to you the IUS Community Project . We
this project a year and a half ago to serve this type of situation. For
those that are not familiar, we [IUS] maintain a repository of packages
that explicitly replace packages in RHEL. So where EPEL is an 'add-on'
repository and has strict policies about conflicting with RHEL... the IUS
project has 'replacement' packages and also has strict policies:
I'm aware of IUS, but it's - sorry - yet another non-well known repository
with software for RHEL out there. In a security audit, some has already to
argue for EPEL, which usually works, because it's well known, but it starts
to get much harder with RPM Fusion already. So I don't want to imagine the
pain at an audit when IUS repository is used and in the end it's equivalent
to our internal company repository, but considered trustful, because it is
Introducing 'postfix26' to EPEL is only good for so long
until branch 2.6
is considered old... or an upgrade is no longer backward compatible...
The Postfix 2.6 branch is already old because RHEL 6 is shipping old stuff
that is EOL at upstream. The only benefit of 2.6 in EPEL 5 is, that RHEL 6
is maintaining that version longer than RHEL 5 lifetime.
In my opinion, there is no point in doing a parallel install for
like this. From my experience I've found that users want something
upgraded, but to work the same as it did before. Meaning... if I upgrade
'php' to 'php53' I want to still be able to call '/usr/bin/php'
'/usr/bin/php-5.3'. Python is an exception because the system is so
heavily dependent on Python that you can't upgrade it... you need to
side-by-side install it.
From my point of view, the same reason applies for postfix. Why should it
make sense to run "postconf26" rather "postconf" etc.?
With regards to PostgreSQL and other services... you have the issue
ports. If postgresql84 installed parallel to postgresql, then what port
would postgresql84 listen on? It gets more complicated... where the
majority of users just want a newer postgres and don't care about
Dito, same for Postfix 2.6. Especially as SMTP forces you to port 25/TCP if
you want to communicate with the rest of the world ;-)
That said, then going the 'replacement' package route... a
lot of trouble
comes in when you consider everything in the distro that is compiled
against the package you are replacing. Providing a 'replacement' package
means you need to ensure that any programs compiled against the original
still work. So anything compiled against postgresql are most likely not
going to work with just postgresql84 installed because there are
different client libraries. So now you need postgresql-libs and
postgresql84-libs installed to be backward compatible. Thats all fine
and dandy if those two packages don't conflict at all.
I'm aware about this, but all of that does not apply for Postfix here. Even
PostgreSQL or PHP are more painful than Postfix in this case. And yes, such
actions still need always to happen with using brain, because glibc210 or a
kernel2632 on EPEL 4 is very likely to cause trouble.
This is all just using postgresql as an example.... but the point
the complexity of the repo and the potential for broken dependencies, or
yum resolution conflicts, or build system failures, etc... just
multiplied by X number of times. Does EPEL want that headache for
potentially hundreds or thousands of 'replacement' packages on top of
what is already in the repo?
From my point of view, it only should be performed, where it makes sense,
but not simply everywhere.
EPEL *adds* packages to RHEL... IUS *replaces* packages in RHEL. It
keeps things a lot cleaner. When you try to mix the two into a single
repo you increase complexity, as well as risk of unknown
incompatibilities and issues.
Your argumentation still leaves the same risk to users if you enable EPEL
and IUS at the same time, so I don't see any benefit of this argumentation.