Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)
a.badger at gmail.com
Wed May 12 03:10:18 UTC 2010
On Tue, May 11, 2010 at 05:48:25PM -0600, Stephen John Smoogen wrote:
> On Tue, May 11, 2010 at 4:44 PM, Rahul Sundaram <metherid at gmail.com> wrote:
> > 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  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.
> 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.
Note that Fedora Guidelines would not pass Conflict and Replace style
packages (such as postgresql8.4 apparently does) at the moment. However,
either that could be changed with a suitable draft and enough thought behind
it or EPEL could allow it where Fedora does not.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the epel-devel-list