On Wed, 2007-10-24 at 11:56 -0800, Jeff Spaleta wrote: > On 10/24/07, Richi Plana <myfedora@xxxxxxxxxxxxxx> wrote: > > I guess I should have added that the reason the update broke yelp and > > devhelp is that they both require a specific version of the virtual > > provides gecko-libs which firefox-2.0.0.8 updates. > > These are well understood problems with how firefox is packaged. These > problems are > some of the reasons why we wanted to get xulrunner packaged so that > the libraries that are being asked for can be packaged seperately from > the firefox application in a reasonable way. This is further > complicated by the fact that pretty much every firefox update is a > security update and as a result is not going to see staging in > updates-testing. > > You are absolutely NOT going to see security updates postponed for > deps to catch up. I can understand and agree that certain updates (Security, mostly) should not be delayed. But 1) how does one do a "yum update" in such a case? and 2) How about a delay system for non-essential updates which break dependencies? The first question is the more important one. If a normal "yum update" won't apply the security update because of dependency issues and the user isn't made readily aware of how to apply the patch anyway given that there are dependency issues, then forcing the patch out only serves a percentage of the population (those who know how to somehow do a "--nodeps" check). If security updates are going to be released without consideration for breakage, doesn't it stand to reason that yum should apply them, breakage notwithstanding? As for the second issue (delaying non-essential updates which break), if we look at the most common use-case, we have the ff. actors: the package maintainer for the package that breaks (A), the package maintainer/s for the package that depend on the breaking one (B), and the users who do "yum update"s (C). It's my contention that (A)'s update should be delayed pending the resolution of (B)'s packages or a certain amount of time has passed. I won't even begin to argue who is responsible for coordinating with who ((A) or (B)). I just believe that (C) shouldn't have to be involved. And yes, I can't wait till xulrunner is its own separate package. -- Richi Plana -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
