Bug 246444

Summary: EPEL python-imaging conflicts with RHEL one
Product: [Fedora] Fedora EPEL Reporter: Janne Blomqvist <blomqvist.janne>
Component: python-imagingAssignee: José Matos <jamatos>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: el5CC: jgranado
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-07-12 17:52:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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):

In EPEL:
http://download.fedora.redhat.com/pub/epel/5/i386/repoview/python-imaging.html

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
No.

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.