Re: Fedora products, to upgrade rather than backport?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Development]     [Fedora Announce]     [Fedora Legacy Announce]     [Fedora Config]     [PAM]     [Fedora General Discussion]     [Big List of Linux Books]     [Gimp]     [Yosemite Questions]

  Powered by Linux