On Wed, 2007-10-24 at 13:25 -0800, Jeff Spaleta wrote: > Point of fact... is there anything which depends on firefox that is > currently experience a depchain problem that is considered a mandatory > application? > Crap like yelp and devhelp and Miro are fundamentally optional > components. And you absolutely are not going to be able to make a > strong enough argument that firefox security updates should be delay > one milliseconds to keep optional packages from breaking. It just isnt > going to fly. People who do not have these optional components > installed will suffer lapses in security unnecessarily. Well, whether yelp and devhelp are "crap" is debatable (I'm a software developer as well as a user and I've yet to find use for either. Don't get me wrong, though. I agree that security updates SHOULD NOT be delayed. But if they can't be applied, then they're effectively delayed. I'm just saying that for certain updates, the user should be given the choice to either force the update and allow it to break the dependency or do an automatic dependency resolution by REMOVING packages (as opposed to adding). I know it's complicated, but if it's worth it, then at least it can go on the table. I've gone ahead and removed "yelp" and "devhelp", but removing dependent packages isn't always a choice. > Something like the yum-skip-broken plugin package helps users make a > choice, by choosing to not install the update because of the dep > problems. I'm not aware of a similar yum plugin which forces the > install of security updates, but perhaps such a plugin should exist to > round out the policy choices for end-users. yum-skip-broken was the answer to my first question earlier, but it's not obvious to everyone. If there really is a move to make Fedora user-friendly (and even as a seasoned admin, I have to say "Anything to make things easier would be appreciated"), then security updates like this should be made easier to work with. But again, even though this example may or may not be the result of a bad choice of app developers in choosing what they depend on, it won't always be the case. -- Richi Plana -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
