On Mon, 2006-05-15 at 16:16 -0400, Jesse Keating wrote: > On Mon, 2006-05-15 at 16:14 -0400, Marc Deslauriers wrote: > > > > Every time we've decided to upgrade a package instead of backporting > > security fixes, we've broken other stuff and have had to work twice as > > hard to get things back into working order. > > > > I don't think we have the resources to upgrade packages. Backporting is > > a lot less work... > > Odd, it would seem the opposite in most occasions to me. We've broken > stuff on RHL releases sure, and even maybe FC1/2, but what about 3, and > coming 4, and such? FL updated PHP a while ago as FC had updated PHP and it seemed the easiest way to tackle the security issues. Of course, the newer PHP was broken so it introduced a bunch of new bugs and I got a ton of email about it. FL had to fix the problem, even though it never got fixed in FC because we broke people's applications. I have a bunch of other examples of upgrades causing grief for us. > If we were better at checking broken deps and > whatnot, would it not be easier to bump package A, respin B and C if > necessary, then beating head on desk for a good long time trying to work > out a backport when there is no backport available (like when our > package version doesn't match any of the close RHELs to steal from?) That works for relatively current releases, like fc4 and fc5. The problem with older releases is to get all the dependencies updated also. Updating gnome versions on a legacy distro is not a very fun thing to do :) Most security issues are easy fixes, and backports are available or aren't that much work. Of course, when the issue required substantial changes, even FL has released upgrades in the past. I'd say let's try and use backports, and use upgrades if it's the most logical solution. Marc.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-legacy-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-legacy-list
