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

[Joel Andres Granados]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>   


-- 
Joel Andres Granados