On Mon, Jun 14, 2010 at 03:48:59PM -0400, Stephen Gallagher wrote:
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.
So for this we probably need to ask the RHEL maintainer to bump epoch on
their packages so that it will upgrade the EPEL version.
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).
For this we'd probably want a libtalloc2 package in EPEL.
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.
This is probably something we want to change ASAP by getting the talloc2
package in and fixed up. I think in the past we've had to take things out
of EPEL when their dependencies couldn't be met due to a RHEL upgrade. :-(
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?
When the EPEL package is new, we end up not being able to submit the EPEL
package as the dependencies cannot be met out of what's available in RHEL.
Perhaps we could do something with RPATH and a private library path in this
case, though. You're probably right that we want to have some rules about
htis so, for example, we'd still build the new library in its own package --
but we'd move the libraries to the private location in %install.
* 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.
<nod> That's the thing to do for the fuutre.
-Toshio