EPEL, RHEL-5Server and RHEL-5Client...
Joel Andres Granados
jgranado at redhat.com
Tue Jul 17 14:23:40 UTC 2007
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
More information about the epel-devel-list
mailing list