python-imaging in EPEL4

Thorsten Leemhuis fedora at leemhuis.info
Mon Jan 21 19:01:53 UTC 2008



On 21.01.2008 19:33, Michael Schwendt wrote:
> On Mon, 21 Jan 2008 18:59:45 +0100, Thorsten Leemhuis wrote:
> 
>> On 21.01.2008 16:30, Joel Andres Granados wrote:
>>> Michael Schwendt wrote:
>>>> On Mon, 21 Jan 2008 15:03:06 +0100, Joel Andres Granados wrote:
>>>>> Michael Schwendt wrote:
>>>>> Don't know what to make of it. So I assume from "You cannot downgrade a package 
>>>>> without asking the epel-signers to delete a newer package", that the solution 
>>>>> is to delete the newer package. right?
>>>> Mail the repo admins in accordance with the EPEL FAQ in the Wiki and
>>>> request removal of the 1.1.6 package. (it is enough to delete the src.rpm
>>>> and let repoprune kill the various binaries)
>>> ok.  sent mail to EPEL signers group. :)
>> Hmmm. Is it wise to remove it? If I understood the discussion correctly
>> then users that already have the currently newest version of
>> python-imaging in EPEL4 installed will never get a update should there
>> ever be released one with a EVRN lower then (none):1.1.6-3.el4.
> But is the newer package in EPEL4 maintained actively? In CVS it is
> back at 1.1.4 already. Will any bug-fix/security-fix released for RHEL4
> be ported to the >1.1.6 pkg in EPEL4? If that doesn't happen, keeping
> the 1.1.6 brown paper-bag in the repo makes no sense.

Sure, it would need to be discussed which spec file we'd continue to
maintain.

>> On the other hand: we cannot increase the epoch only in EPEL4 because
>> then the upgrade path to RHEL5 is broken (still/again).
>> Which of the two things is worse?
> The third thing. ;) Replacing a pkg from RHEL ;-P

That would only happen on update afaics.

> and an attitude like
> "damage is done, we can't revert it". Next time it happens with a different
> package, you won't revert it either?

I didn't suggest that. I actually think removing is best as well. But
doing such things should not be the decision of those that have access
to the repo alone, thus I asked for options here on the list.

CU
knurd




More information about the epel-devel-list mailing list