Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

Rahul Sundaram metherid at
Wed May 12 00:12:31 UTC 2010

On 05/12/2010 05:18 AM, Stephen John Smoogen wrote:
> Ok having dealt with several ugly packages.. I have to agree that
> parallel installed packages is the way to go for most webapps. The
> issues I see will be dealing with getting them through the Fedora
> packaging reviews AND their Fedora upstream maintainers. Both who have
> an interest in not having this happen as it duplicates work and makes
> their lives hard in some ways.
> I am not 'against' this proposal, I just think we will need to flesh
> out a lot more on this and need to get input from various places on
> how to better do this.

A few more thoughts on why I think a merge is appropriate.  Fedora has
traditionally been focussed on a single runtime for various things.  The
latest Python,  latest PHP and so on but while this was somewhat
appropriate for a fast moving distribution, it has become increasingly
evident that we cannot sustain that focus and have to introduce parallel
installable versions.  Python is certainly moving towards that path with
Python 3 in Fedora and Python maintainer has already indicated he would
be willing to do Python27 and more in Fedora and EPEL as and when
needed.  Ruby SIG has similar plans as well.   That's the case for
Fedora which influences EPEL directions as well.   On the other hand, 
what Red Hat does with the base repo can and should influence EPEL
directions as well.  We now have a precedent with Postgres and it is
clear that customers are demanding it with the growing gap between EL
releases.  Within EPEL,  there is a even higher need for similar
flexibility because we have a larger package set.  As long as the
conflicts are managed on a case by case with a focus on infrastructure
packages,  I believe we should accommodate such interests because it
provides better value and EPEL users (and Red Hat customers) are doing
it on their own anyway.  By merging the infrastructure and enforcing a
review process, we will bring into fold and provide higher quality for
what would exist otherwise in perhaps a more loosely defined way.


More information about the epel-devel-list mailing list