Strange package dependency problem
seth vidal
skvidal at phy.duke.edu
Mon Mar 22 03:42:42 UTC 2004
> We're not running yum, we're using an in house tool since we couldn't
> find anything that would meet all our requirements[0], for some
> combinations of host/rpm we want to specify rpm versions tighter than
> "what's available"
this is something in the cards for yum's next major version which I'm
working on a little bit as often as I can.
there are a lot of things I'd like to get implemented and installing
random versions of things is something I'd like to do nicely.
> In the tree, no I don't "know" that. There could be no unresolved deps
> in the tree but at the same time there may be dependancy problems with a
> host running one of about 100 rpms sets that aren't our standard set, we
> could write something to check this but the pain level hasn't hit high
> enough to warrant it - yet. though that seems to be on the cards for
> this summer.
I hope to have a working system in place for the next version of yum
before summer hits. This will be the framework I want to use to add a
fair number of useful features. In short, stay tuned. :)
> No, we're running a global update having done a reasonable set of
> checks, we expect the system to let us know about failed rpms,
> dependancy errors or not.
but you also expect it to install any and everything it actually can, is
that right?
> I didn't say it wasn't an unreasonable error, merely pointed out that
> unresolved dependancies were not the only problems you'll run into if
> you're running automated updates, hence monitor/report the status of
> your updates.
again we get into the issue of error codes and how to report back, it
gets increasingly complex, I've found to report a percentage of
failure/success.
-sv
More information about the fedora-test-list
mailing list