On Mon, Jun 14, 2010 at 05:15:38PM -0400, Stephen Gallagher wrote: > > >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. > > 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. 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. > In my opinion, taking this package out of EPEL (and all of its > descendents, including SSSD which I am aware of being used by a > number of very large deployments) would be far more disruptive than > simply bending the "updating package" rule for a few months. > Unless I missed something, there'd be no breakage in the EPEL repository if you get libtalloc2 in. > > * This is not a decision I made without the input of many others on > #fedora-devel > You need to be discussing this on #epel and in this mailing list and the packagers of epel (including yourself) can then come to a unified decision. What you've done is say that the rules of epel don't apply to your package without getting buyin from the other people who have to live by the rules which is disrespectful of them. * Note: not arguing that the rule shouldn't be changed (although I don't think that it's waranted i nthis instance), just that deciding to ignore it for your package is the wrong way to approach the problem.
Description: PGP signature