[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 installation 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 with 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" situation!!! 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 redhat com
https://www.redhat.com/mailman/listinfo/epel-devel-list


--
Joel Andres Granados


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]