Hi all:
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.
Regards.
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 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"). 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
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
On 17.07.2007 13:13, Joel Andres Granados wrote:
Thorsten Leemhuis wrote:
On 17.07.2007 12:13, Joel Andres Granados wrote: 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.
/me can't follow, sorry.
EPEL in general and the Repos EPEL4 and EPEL5 are still not officially started; that's planed for next weeks Thursday.
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".
And the users isn't helped if we fix one error by making another (bigger) one.
(¹) -- we likely should put something (test-scripts?) in place to make sure something similar does not happen again
IMO, This is VERY necessary.
Any volunteers?
[...]
CU thl
Thorsten Leemhuis wrote:
On 17.07.2007 13:13, Joel Andres Granados wrote:
Thorsten Leemhuis wrote:
On 17.07.2007 12:13, Joel Andres Granados wrote: 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.
/me can't follow, sorry.
EPEL in general and the Repos EPEL4 and EPEL5 are still not officially started; that's planed for next weeks Thursday.
I thought EPEL4 was official, I see that they are both no out yet :)
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".
And the users isn't helped if we fix one error by making another (bigger) one.
Just to be clear. the process to install (if you have already installed 1.1.6) is to remove the current package, then install from repos?
if the answer is yes. And having in mind that this situation might present itself more than once in the future. Will this be the policy to handle all of these situations? Will the message to the user be "to make sure you updates are done correctly and no unexpected behaviors pop up with corner cases, uninstall EPEL package and install it from new/current repo"? Its just something to think about, I know its not a solution !! I'll be on the look out for what is decided on tomorrows meeting.
(¹) -- we likely should put something (test-scripts?) in place to make sure something similar does not happen again
IMO, This is VERY necessary.
Any volunteers?
The scripts is important, the action taken when the scripts finds something is more important.
Regards.
On 17.07.2007 14:23, Joel Andres Granados wrote:
Thorsten Leemhuis wrote:
On 17.07.2007 13:13, Joel Andres Granados wrote:
Thorsten Leemhuis wrote:
On 17.07.2007 12:13, Joel Andres Granados wrote:
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".
And the users isn't helped if we fix one error by making another (bigger) one.
Just to be clear. the process to install (if you have already installed 1.1.6) is to remove the current package, then install from repos?
Yes.
if the answer is yes.
then what?
And having in mind that this situation might present itself more than once in the future.
Just my 2 cent: We should do our best to prevent that such a situation happen again in the future and not design policies for accidents.
[...]
CU thl
Thorsten Leemhuis wrote:
On 17.07.2007 14:23, Joel Andres Granados wrote:
Thorsten Leemhuis wrote:
On 17.07.2007 13:13, Joel Andres Granados wrote:
Thorsten Leemhuis wrote:
On 17.07.2007 12:13, Joel Andres Granados wrote:
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".
And the users isn't helped if we fix one error by making another (bigger) one.
Just to be clear. the process to install (if you have already installed 1.1.6) is to remove the current package, then install from repos?
Yes.
if the answer is yes.
then what?
Will this be the policy to handle all of these situations? Will the message to the user be: "to make sure you updates are done correctly and no unexpected behaviors pop up with corner cases, uninstall EPEL package and install it from new/current repo"?
And having in mind that this situation might present itself more than once in the future.
Just my 2 cent: We should do our best to prevent that such a situation happen again in the future and not design policies for accidents.
I agree. Maybe there should be some sort of policy stating that the version of the package included in EPEL will be the one that dates back to the initial release of the main RHEL version. In this case python-imaging changed from 1.1.5 to 1.1.6 in Mon Feb 5 2007 (change log) and RHEL5 was released in 2007-03-14. In this particular case, this hypothetical policy would not have stopped the mistake from occurring. But the policy can further be refined stating that the package has to have a certain maturity level to be included in EPEL, say for example 6 months after release (just thinking out loud). So to be included in EPEL just select the version of the package that was released a certain period of time before the main RHEL release.
I really don't think I'm making myself clear..... Let me expand with an example: the policy would say: the version of foo to be included in EPEL/e(N) [1] will be the one that, at the moment of RHEL(N)'s release, had at least X amount of months of existence. :)
So, (assuming X=6) 1.1.6 wouldn't have been considered because it was released on December 3-2006, 4 months and 11 days before RHEL5's release. 1.1.5 would have to be used because *it* was released on March 28-2005, more than 6 months before RHEL5's release.
And in case RHEL(N) decides, for whatever reason, to include the newest version of the package (version released X months before RHEL), then all EPEL has to do is, build an newer version :)
The question is now, what is the value for X?
[1] N being the version.
Regards
PS: It's kinda difficult to explain, tell me if I need to send a graph or picture or slide presentation :) **
[...]
CU thl
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On 7/17/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
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 and say loudly "apologize" and "we are sorry"(¹). Not ideal, but problem solved.
Well, to make things clear, python-imaging was branched for EPEL because plague builds in *EPEL5* were failing due to unsatisfied dependency on python-imaging, at least when I tried to build it on May 31st. This means that back then the 5Client packages were not available for plague building -- has that changed?
Regards,
On 17.07.2007 14:24, Konstantin Ryabitsev wrote:
On 7/17/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
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 and say loudly "apologize" and "we are sorry"(¹). Not ideal, but problem solved.
Well, to make things clear, python-imaging was branched for EPEL because plague builds in *EPEL5* were failing due to unsatisfied dependency on python-imaging, at least when I tried to build it on May 31st. This means that back then the 5Client packages were not available for plague building -- has that changed?
dgilmore might be able to answer.
But at least my package mail-notification (which requires a package that's only available in 5Client) built fine for EPEL5.
CU thl
I think the right solution is, to move add python imaging to the core server. In that way it will be available to every user.
I have to review why it was moved to the Client only (it will be available to server customers in a separate channel containing the Client-only packages as soon as the RHN profiles get updated). I assume dependencies where only from that Repo.
We'll target that for 5.1
Regards,
Daniel
On Tue, 2007-07-17 at 12:33 +0200, 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 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"). 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
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Joel Andres Granados wrote:
Hi all:
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.
Regards.
And what about EPEL/e4, the EPEL wiki says to use code form fedora core 3. FYI, the version for fc3 was 1.1.4 for python-imaging. (will changing to 1.1.4 with a spec from that time be enough?). Moreover, is there an additional way to build EPEL packages. I'm following http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo wiki for the builds. Is this correct? or should I be going with a different process?
regards.
On 17.07.2007 14:52, Joel Andres Granados wrote:
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.
And what about EPEL/e4, the EPEL wiki says to use code form fedora core 3.
That the advice, yes.
[...] Moreover, is there an additional way to build EPEL packages. I'm following http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo wiki for the builds. Is this correct?
The old Extras procedure applies; e.g. update cvs, run "make tag build"; koji and bodi, which are used for F-7 and rawhide are not yet used for EPEL.
CU thl
Thorsten Leemhuis wrote:
On 17.07.2007 14:52, Joel Andres Granados wrote:
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.
And what about EPEL/e4, the EPEL wiki says to use code form fedora core 3.
That the advice, yes.
[...] Moreover, is there an additional way to build EPEL packages. I'm following http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo wiki for the builds. Is this correct?
The old Extras procedure applies; e.g. update cvs, run "make tag build"; koji and bodi, which are used for F-7 and rawhide are not yet used for EPEL.
^^^^ this is really nice to know, I am familiar with the EPEL way of doing it. Can you direct me to the wiki, tutorial or info page. Thx.
CU thl
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Joel Andres Granados wrote:
Thorsten Leemhuis wrote:
On 17.07.2007 14:52, Joel Andres Granados wrote:
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.
And what about EPEL/e4, the EPEL wiki says to use code form fedora core 3.
That the advice, yes.
[...] Moreover, is there an additional way to build EPEL packages. I'm following http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo wiki for the builds. Is this correct?
The old Extras procedure applies; e.g. update cvs, run "make tag build"; koji and bodi, which are used for F-7 and rawhide are not yet used for EPEL.
^^^^ this is really nice to know, I am familiar with the EPEL way of doing it. Can you direct me to the wiki, tutorial or info page. Thx.
^^^^ this is really nice to know, I am *Not* familiar with the EPEL way of doing it. Can you direct me to the wiki, tutorial or info page. is it in http://fedoraproject.org/wiki/PackageMaintainers/UsingPlagueClientFaq?highli... Thx.
epel-devel@lists.fedoraproject.org
-
Daniel Riek -
Joel Andres Granados -
Konstantin Ryabitsev -
Thorsten Leemhuis