Bug 577516 - libtalloc from EPEL conflicts with RHEL version
Summary: libtalloc from EPEL conflicts with RHEL version
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: libtalloc
Version: el5
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-27 18:33 UTC by Trond H. Amundsen
Modified: 2010-04-26 11:34 UTC (History)
3 users (show)

Fixed In Version: libtalloc-2.0.1-2.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-19 23:23:20 UTC
Type: ---


Attachments (Terms of Use)
Illustration of the problem (2.32 KB, text/plain)
2010-03-29 09:28 UTC, Trond H. Amundsen
no flags Details
EPEL package replaces RHEL package (2.19 KB, text/plain)
2010-04-07 10:43 UTC, Trond H. Amundsen
no flags Details

Description Trond H. Amundsen 2010-03-27 18:33:56 UTC
Description of problem:

The libtalloc package in EPEL conflicts with the official RHEL5.4 package of the same name in the Supplementary channel. Certain packages from RHEL, e.g. samba3x, depends on the older libtalloc from RHEL. This causes yum conflicts if those packages are installed. This violates the EPEL policies as I understand them. The libtalloc in EPEL should be removed and/or renamed.

Version-Release number of selected component (if applicable):

2.0.1-1.el5

How reproducible:

Always.

Steps to Reproduce:
1. Install samba3x packages and libtalloc from RHEL5.4 supplementary channel
2. Run 'yum -y update'
  
Actual results:

Package conflict.

Expected results:

No package conflict.

Additional info:

Comment 1 Trond H. Amundsen 2010-03-29 09:28:33 UTC
Created attachment 403245 [details]
Illustration of the problem

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

Comment 2 Stephen Gallagher 2010-03-29 15:52:55 UTC
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.

Comment 3 Trond H. Amundsen 2010-03-29 16:30:57 UTC
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.

Comment 4 Trond H. Amundsen 2010-03-29 17:01:49 UTC
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).

Comment 5 Trond H. Amundsen 2010-03-29 17:27:47 UTC
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.

Comment 6 Fedora Update System 2010-03-30 00:10:32 UTC
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

Comment 7 Fedora Update System 2010-04-01 21:03:27 UTC
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

Comment 8 Trond H. Amundsen 2010-04-07 10:40:49 UTC
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

Comment 9 Trond H. Amundsen 2010-04-07 10:43:10 UTC
Created attachment 404896 [details]
EPEL package replaces RHEL package

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

Comment 10 Stephen Gallagher 2010-04-07 11:23:33 UTC
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.

Comment 11 Fedora Update System 2010-04-19 23:23:15 UTC
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.

Comment 12 Ray Van Dolson 2010-04-23 23:43:31 UTC
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?)

Comment 13 Stephen Gallagher 2010-04-26 11:34:50 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.