Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

Rahul Sundaram metherid at gmail.com
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.

Rahul




More information about the epel-devel-list mailing list