On 1/24/06, Jesse Keating <jkeating(a)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.