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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
