On 1/24/06, Jesse Keating <jkeating@xxxxxxxxxxxxxxx> 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
