Bug 246444 - EPEL python-imaging conflicts with RHEL one
EPEL python-imaging conflicts with RHEL one
Product: Fedora EPEL
Classification: Fedora
Component: python-imaging (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: José Matos
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-07-02 05:57 EDT by Janne Blomqvist
Modified: 2007-07-16 10:01 EDT (History)
1 user (show)

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

Attachments (Terms of Use)

  None (edit)
Description Janne Blomqvist 2007-07-02 05:57:54 EDT
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 13:20:46 EDT
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 13:33:43 EDT

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 13:52:38 EDT
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 14:00:08 EDT
Wait, what happens for those who have 5Server?
Comment 5 Stephen John Smoogen 2007-07-12 14:32:51 EDT
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 10:01:27 EDT
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.