Request for policy clarification

[Dennis Gilmore]

On Monday, June 14, 2010 02:48:59 pm 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.
> 
> 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.
this is not at all acceptable and needs to be re done so it is done according 
to the letter of the epel guidelines

> 
> 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.

The issue has to be fixed by Red Hat,  they are the ones that created the 
problem they have to fix it we can't.  you could package libtalloc2  to not 
conflict at all with rhel and allow rhels package to be installed and work fine.


in the instance of rhel doing something that makes a package not work in epel 
and there is no way to package things so that they can all live happily and 
work we have to remove the package from epel and send an email to the announce 
list stating so and why. 

This is one of the pain points in having Red Hat go off and do its own thing 
and not considering us.  we can only work as much magic as we can to make 
things work.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20100614/c3008e8d/attachment.sig>