Request for policy clarification

[Stephen Gallagher]

Recently, I've had to deal with a rather touchy situation in EPEL. I 
built the package libtalloc of version 2.0.1 as a dependency on several 
other packages that I was building: libtevent, libldb and sssd.

This was released and entered EPEL5 stable during the lifetime of RHEL 5.4.

When RHEL 5.5 was released, however, it contained a new package, 
samba3x, that built as a subpackage libtalloc 1.2.0. So now there is a 
conflict in EPEL, which violates the "EPEL won't upgrade packages in 
RHEL" rule.

However, we also have a responsibility to those relying on this package 
in EPEL (as libtalloc 1.2.0 is too old to work as the dependency for 
libldb or sssd).

My case was somewhat fortunate: libtalloc 2.x had gone through an soname 
bump. I was able to (in a very hideous hack) rebuild a copy of libtalloc 
1.2.0 from the samba3x SRPM and repackage it into my EPEL libtalloc 2.x 
package. Thus, any users who were using e.g. SSSD in EPEL 5 will be able 
to update to RHEL 5.6, even if it is in violation of the "EPEL won't 
upgrade packages in RHEL" rule.

However, I think we need a general policy written up for EPEL on how we 
should handle other packages that end up in this situation. For example, 
what do we do if a package has NOT had an soname bump, and some EPEL 
packages cannot function with the older version of the library in RHEL?

Obviously, this is a problem that must be solved in EPEL, not in RHEL. 
The RHEL policy will always be (and should be) "If you install a 
third-party repository, your problems are your own".


* Last note: I am working with the samba3x team at Red Hat to eliminate 
this conflict in RHEL 5.6 by pulling libtalloc 2.0.1 into RHEL proper 
and building samba3x against it.

-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/