Bug 246444 - EPEL python-imaging conflicts with RHEL one
Summary: EPEL python-imaging conflicts with RHEL one
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: python-imaging   
(Show other bugs)
Version: el5
Hardware: All Linux
Target Milestone: ---
Assignee: José Matos
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-07-02 09:57 UTC by Janne Blomqvist
Modified: 2007-07-16 14:01 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-12 17:52:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Janne Blomqvist 2007-07-02 09:57:54 UTC
Description of problem:

The version of python-imaging in EPEL/el5 conflicts with the package provided by
EL5. This is in conflict with the stated goal of the EPEL project to never
replace core packages.

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


Version 1.1.6-3.el5

in RHEL5: 1.1.5-5.el5

Now, it would be nice if python-imaging and python-imaging-devel in EPEL would
be removed, and python-imaging-sane and python-imaging-tk rebuilt against the
EL5 core packages.

Comment 1 Joel Andres Granados 2007-07-12 17:20:46 UTC
As I understand it the EPEL project was founded on the base of providing
complementary packages to the fedora based RedHat Enterprise Linux.  When I go
look for this package in the RHEL repos I see it appears in the RHEL client so,
IMO there is no need for this package in EPEL.
Am I missing something here?????

Comment 2 José Matos 2007-07-12 17:33:43 UTC

I requested the building for EPEL 5 since the package was already in EPEL 4. I 
missed to notice that it was already in one of the RHEL repos. :-(

So the right think is to request the administrative removal of this package 
from EPEL 5. Regarding the subpackages python-imaging-sane and 
python-imaging-tk the easier way is to ask for their build in upstream RHEL...

Comment 3 Joel Andres Granados 2007-07-12 17:52:38 UTC
As per https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240415#c5, I'm
closing this bug as a not a bug. for EPEL/el5

Comment 4 Konstantin Ryabitsev 2007-07-12 18:00:08 UTC
Wait, what happens for those who have 5Server?

Comment 5 Stephen John Smoogen 2007-07-12 18:32:51 UTC
I think the solution is that the version that is built for EPEL-3/4/5 is the
same as upstream which in this case would be the 1.1.5 version. Building that
RPM while not 'the latest' would make sure that any updates/security fixes
upstream are caught and conflicts do not occur.

Comment 6 Joel Andres Granados 2007-07-16 14:01:27 UTC
Does this situation actually break something?

In EPEL there are two pkgs that depend on python-imaging (Plone and
python-docutils).  AFAIK they use only the image module from PIL.  Moreover I
went through the comments of the spec file and
http://effbot.org/zone/pil-changes-116.htm, I did not see anything that
suggested a backward compatibility issue.

regarding comment #5: If Someone has python-imaging from EPEL/el4(1.1.6) and
wants to upgrade to EPEL/el5 (1.1.5) yum will not recognize EPEL/el5 as greater.
 This could be harmless in some occasions but I'd rather avoid nvr
inconsistencies.  This basically applies for people that already have
python-imaging from EPEL/el4.

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