On 1/24/06, Jesse Keating <jkeating j2solutions net> wrote:
>
> Working around broken deps is not a smart thing to automate. While
> there are hard deps, there maybe some soft deps that are just unknown.
> When testing, tests are performed with ALL the updates in place, not a
> smattering of them. It has been discussed many times that leaving
> packages in old to work around broken deps is not something that will be
> seen in the yum space. When yum errors, it errors on the side of
> protecting the user from potentially broken system states. Smart
> however takes a different stance, one that some users like until their
> system crashes in weird ways because of an odd update state. Thus far
> in rawhide space the gamble has paid off a bit, but once you move into
> released space, add in a few repos of choice, lets see how long it takes
> before stuff starts acting oddly w/ smart.
>
I haven't used smart so I can't say if it's any good, but I think the
behaviour of it in this regard seems more logical than yum's method.
Let's say there are 30 available updates, fixing 20 bugs (maybe
including a couple of security fixes), and one package is unable to be
updated because of a dep. issue. Let's also say that having a
'smattered' update would introduce 2 bugs because of unforeseen
incompatibilities.
Using yum:
- 20 bugs, including possible security issues, are not fixed until the
dependencies are resolved.
- Incompatibility in package may never be found.
Using smart:
- 20 bugs are fixed.
- 2 new bugs are introduced.
- Incompatibilities in packages are found and hopefully reported.
I think I would prefer the latter.
Just my two cents,
n0dalus.