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
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
bad packages that don't work properly :(, then again, I might be taking
the "ignore user" to seriously:)
and python-docutils against the 1.1.5 package from EL (if that's
Problem3 -- no python-imaging in EL5Server: Not solved yet, but under
(¹) -- 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
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
gotten in the way.
Moreover, this might be a simple "erase from repos and rebuild the good
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?  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.
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
epel-devel-list mailing list
Joel Andres Granados