rawhide report: 20060121 changes

n0dalus n0dalus+redhat at gmail.com
Tue Jan 24 01:26:13 UTC 2006

On 1/24/06, Jesse Keating <jkeating at 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

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,

More information about the fedora-devel-list mailing list