Bug 577516

Created attachment 403245 [details]
Illustration of the problem

Added an attachment that shows output from rpm and yum to further illustrate the problem.

EPEL makes no guarantees of compatibility with versions in RHEL channels outside of the primary channel. All packages in the RHEL 5.4 Supplementary Channel are considered tech previews.

I disagree. There is nothing that suggests that packages in the supplementary channel are tech previews. The channel description is

"Server supplementary software with non-standard SLAs and/or licenses"

Take a look at the packages it contains.. mostly various Java versions, acrobat reader etc. While the samba3x packages was introduced as (and probably still is) a tech preview, the most packages in the supplementary channel are not.

BTW, if EPEL does not guarantee compatibility with packages outside the primary channel, you're also saying that EPEL may replace KVM or Xen packages, as these are found in the "Virtualization" channel. I find it hard to believe that this is the case. While the EPEL FAQ goes to great lengths to ensure that EPEL packages doesn't replace RHEL packages, it doesn't at all mention that this only applies to the primary channel.

I'm sorry to whine about this, but you should double-check these claims.

I forgot to add that the samba3x and libtalloc packages are moved from supplementary to base as of RHEL5.5, at least from what I can see of the RHEL5.5 beta DVD and supplementary CD contents. (The beta channels in RHN are emptied, so I'm unable to verify this within RHN).

Just to answer my own question...

The EPEL "Policy for Conflicting Packages" states that:

* EPEL packages must never conflict with packages in RHEL Base (Including Advanced Platform). 
* EPEL packages can conflict with packages in other RHEL channels.

So I withdraw my previous comments about this violating policies. But on the other hand, if I'm right about the move to base, you will soon have a "real" package conflict to deal with.

libtalloc-2.0.1-2.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/libtalloc-2.0.1-2.el5

libtalloc-2.0.1-2.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libtalloc'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/libtalloc-2.0.1-2.el5

Thanks for the swift reply and the fix. There is no longer a package conflict, i.e. yum no longer complains. However, I'm not entirely comfortable with this fix. The new package replaces the official package from RHEL, which is something that the EPEL FAQ explicitly says won't happen:

  Does EPEL replace packages provided within Red Hat Enterprise Linux or layered products?

  No. EPEL is purely a complimentary repository that provide add-on packages.

Is this fix (replace the RHEL package) according to EPEL policies?

-trond

Created attachment 404896 [details]
EPEL package replaces RHEL package

Added an attachment that shows how the updated libtalloc replaces the RHEL package.

Ok, here's the problem (and there's no easy solution).

At the time when this package was created, RHEL 5.4 was the released version. There was no conflict with this package in that release. It was therefore acceptable to create a new package to provide this functionality.

When RHEL 5.5 was released, it carried the samba3x package and subpackages, one of which provided libtalloc as a subpackage. Unfortunately, this was not coordinated and it is providing a very old (and incompatible) version of libtalloc as compared to the one available in EPEL.

Now, the situation is that, because the EPEL package already exists, there may be users that already have it installed. In this case, the EPEL policy of "must maintain compatibility and stability" must supersede the "Don't replace packages" policy.

Here's why: I don't control the samba3x SRPM, so I can't demand that it add an 'Obsoletes: libtalloc > 2.0.0' in the spec file. RPM and yum do not allow you to remove a package during an update otherwise. I can't resolve this the same way as #577902 (by removing all of the files that were in conflict from the package and adding Requires: <the conflicting package>), because the samba3x subpackage and the standalone package both share the same name and the samba3x version is an older n-v-r.

So, the only way to maintain compatibility for both versions is to include a compatibility library in the libtalloc package that will guarantee support for the older shared library.

It's not an ideal solution, but it's the only one we can come up with.

libtalloc-2.0.1-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

It might be nice to include a README.EPEL or README.Fedora explaining this situation, pointing to this bug and maybe even offering a suggestion on how to maintain full "supportability" by Red Hat.

I am just throwing in an exclude=libtalloc in my EPEL repo files for now.

Longer-term, perhaps we should open a SEG SR with RH to update their libtalloc to the latest version and ultimately move it into "Base".

Your newer version of libtalloc does seem to work fine with the Supplementary channel samba3x however (I guess perhaps you included the compat. lib?)

I'm not permitted to speak about future Red Hat Enterprise Linux releases, but I will note that Product Management is aware of this issue, so I would probably consider it reasonable to expect that it will be addressed in the 5.6 release.

And yes, libtalloc-2.0.1-2.el5 contains the compatibility library libtalloc.so.1 in addition to the newer libtalloc.so.2. So at the very least, we're no longer in conflict.