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

Re: firefox-2.0.0.8 Upgrade Problems in F7



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


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