Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

Rahul Sundaram metherid at
Tue May 11 22:44:05 UTC 2010

On 05/12/2010 04:00 AM, BJ Dierkes wrote:
> Granted, postgresql84 is likely a one-off for Redhat because they and Fedora Infrastructure use PgSQL.  However on this same note, the IUS Community Project [1] has the same exact process for 'replacing' RHEL packages with updated counterparts (i.e. php replaced by php52, php53, etc).  Being the primary maintainer of IUS, my question has to do with the fact that IUS relies on EPEL and is meant to compliment both RHEL and EPEL with optional upgrades for packages that are locked (incompatible upgrade paths) on a branch and can't update.  The last thing I want is to maintain a package in IUS, that would be accepted and benefit EPEL.   Seeing as RHEL allows the practice of Conflict/Replace ... is this a policy that EPEL would also embrace?  Or is it something we want to strictly avoid as, with anything, it has the potential to complicate things.

IMO,  I think it is time for EPEL to merge with IUS.  We should strive
to create parallel installable packages as much as possible but if there
is a explicit package conflict and NOT a silent obsolete, then it should
be allowed.  I would avoid integrating apps that build on such conflict
infrastructure packages however.


More information about the epel-devel-list mailing list