[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Introduction of overlapping postfix26 package in EPEL-5?


On Tue, 19 Apr 2011, BJ Dierkes wrote:
> Let me first introduce to you the IUS Community Project [1].  We started
> 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
maintained in-house.

> 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...
> then what?

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 packages
> 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' and not
> '/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 of
> 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
> backward compatibility.

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 is,
> 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.


Attachment: pgppYvJRW3sM9.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]