EPEL, RHEL-5Server and RHEL-5Client...

Joel Andres Granados jgranado at redhat.com
Tue Jul 17 11:13:43 UTC 2007

Thorsten Leemhuis wrote:
> On 17.07.2007 12:13, Joel Andres Granados wrote:
>> Regarding the python-imaging package...
>> What is the matter with including the 1.1.6 version in EPEL/el5?  does 
>> it break anything?
>> Both Plone and python-docutils (deps in EPEL) use the Image library from 
>> PIL and this library does not have any
>> backward compatibility issues.  additionally, RHEL5-client has no 
>> package that depends on
>> python-imaging.  So I say KISS, and ship 1.1.6 with the EPEL/el5.  I 
>> know it goes against the EPEL policies,
>> but I think its much better that messing with nvr.
> This way lie dragons.
> "EPEL does not replace packages from the distribution it was build for"
> is IMHO not debatable -- just as it was in Extras before the merge.
> For the situations at hand:
> Problem1 -- python-imaging was EPEL: We made a error, but we are still
> in the testing/buildup phase, so we can still remove it from the repo

Is this true for EPEL/el4 and EPEL/el5?  I ask because I have them both 
in the CVS
and assumed that EPEL/el4 was an already *stable* release.

> and say loudly "apologize" and "we are sorry"(¹). Not ideal, but problem
> solved.
> Problem2 -- python-imaging had a higher EVR then the EL5Client package:
> Ignore those users that got the newer python-imaging from EPEL (see
> Problem 1: "EPEL is still in testing" and "apologize"). 

IMO this is also very precarious "to ignore the user".  Someone might 
not get the
"We made a mistake we are very sorry" and have some sort of updating or 
problems.  After they are solved (if they are solved) EPEL would be 
related with
bad packages that don't work properly :(,  then again, I might be taking 
the "ignore user" to seriously:)

> Rebuild plone
> and python-docutils against the 1.1.5 package from EL (if that's
> needed). Solved.
> Problem3 -- no python-imaging in EL5Server: Not solved yet, but under
> discussion.
> CU
> thl
> (¹) -- we likely should put something (test-scripts?) in place to make
> sure something similar does not happen again

IMO, This is VERY necessary.  This whole discussion wouldn't have 
happened if
RHELClient wouldn't have had the 1.1.5 version.  EPEL would have shipped 
the latest version for Client and Server.  In other words the policy 
wouldn't have
gotten in the way.
Moreover, this might be a simple "erase from repos and rebuild the good 
one" situation
because it is the "testing" version.  But what will happen when EPEL 
ships what is thought to
be the best choice for a package and turns out that RHEL introduces the 
same package but with
a more recent version? [1]  That will not be a "lets erase and rebuild" 
The idea of putting a "0." in the release is a good one, but I really 
don't feel comfortable messing with
the version in that way.  Its something additional to think about when 
doing builds and it might be an
opportunity for another bug to pop up.

[1]What I mean is that a package is introduced in one of the flavors 
(Server, Client) and not on the other.
      Because if it is introduced in both, the solution is to erase it 
from EPEL.
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list

Joel Andres Granados

More information about the epel-devel-list mailing list