Request for policy clarification

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20100614/3df4157a/attachment.sig>