Request for policy clarification

[seth vidal]

On Mon, 2010-06-14 at 18:46 -0400, Toshio Kuratomi wrote:
> > 
> > Well, in this particular instance, given that the two versions of the
> > package had different sonames, I judged* that the rule of "Don't
> > break existing deployments" was more important than the rule of
> > "Don't upgrade RHEL packages" in this case. My EPEL package is
> > bundling a compatible version of the older soname (built directly
> > from the sources in the RHEL SRPM) so as to minimize the damage until
> > RHEL 5.6 can sort this out properly.
> > 
> This isn't how it works.  You have the ability to fix this by creating the
> libtalloc2 package in EPEL5.  So you've broken the expectations of users
> using EPEL without a reason.

What the hell? 

I don't think you understand the order of ops:

1. there was a libtalloc in epel
   there was no libtalloc in rhel
2. rhel5.5 came out
   libtalloc came out of samba3x in rhel
   the version of libtalloc in samba3x (in rhel)has ALWAYS been older   
   than the  one in epel.
   the version of libtalloc in rhel is not even a normal libtalloc it 
   is a special one


So if he introduces a libtalloc in epel to fix this he can carry the
libtalloc from rhel, temporarily, to do so. B/c the samba3x pkger has
already agreed to fix this in rhel 5.6



> 
> EPEL has already judged that breaking existing deployments is the lesser
> evil compared to replacing packages in RHEL so you'd need to discuss the
> idea with the other packagers in EPEL and decide on whether the policy
> should change rather than ignoring the policy.

I think the policy should be ignored in this case. we're leaving systems
broken  and making it so that 'yum install samba3x' will not work on
rhel5.5 systems  w/epel enabled for the next 4-5months.


> Unless I missed something, there'd be no breakage in the EPEL repository if
> you get libtalloc2 in.

Except you have to obsolete the older pkg to keep from breaking existing
installs.

That's the problem!

-sv