Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

[BJ Dierkes]

Hello all,

Lately there have been a number of package additions/requests to Fedora/EPEL that introduce new versions of a package, whilst allowing the original package to remain in-tact.  Some examples:

python26 - https://bugzilla.redhat.com/show_bug.cgi?id=573151
python3  - https://bugzilla.redhat.com/show_bug.cgi?id=554799
sqlite36 - https://bugzilla.redhat.com/show_bug.cgi?id=571458


These examples are all parallel installable.  Python has a separate 'site_packages' directory based on major branch version (stock = 2.4, python26 = 2.6, python3 = 3.1).  SQLite has a unique binary path (stock = /usr/bin/sqlite3, sqlite36 = /usr/bin/sqlite36).  That said, RedHat has also begun introducing newer versions of packages that conflict/replace with their previous counterparts. 

Example: postgres84

Conflicts: postgresql < 8.4
Provides: postgresql = %{version}-%{release}


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.

It was my understanding previously that these types of packages would be rejected because they 'Conflict with stock RHEL base channel packages'.  However I think the policy of not conflicting doesn't really apply if a user wants the conflicting package and explicitly has to remove the stock package and install a comparable package that 'provides' it (postgresql84 Provides: postgresql).

References:

[1] http://iuscommunity.org, http://dl.iuscommunity.org/pub/ius

---
derks