> 1. yum update > > went fine > and give this as its last line: > > package newpg needs libpth.so.14 (not provided) libpth is being updated to a different version or obsoleted and will soon not be there. Therefore newpg won't need one of its requirements. > I figured, nice yum detects broken dependencies, while updating. > > 2. yum list updates so to be clear - yum list updates and yum update are parallel but yum list updates and yum upgrade are not - upgrade considers obsoletes, updates does not. So if you look at that list here is what happens: yum updates the system - it gathers that it should update pth. newpg depends on libpth.so.14 pth is being updated to 2.0.0 - no longer libpth.so.14 so it's not that any of the packages that will be installed have a broken depedency its that newpg (which is currently installed) will be broken. > This puzzles me, since I don't think every package in the upgrade list > needs 'libpth' so why does it stop? It stops b/c something in that set of pkgs has an undetermined dependency. > It would be nice if it just ignored all packages depending on this and > mentioning something like this: > > broken dependency: libpth.so.14 > package newpg needs libpth.so.14 (not provided) > etc. Ok - but then what - remove pth from the update list, ok, then recalculate deps based on that trans. That is not default behavior I'd want. Maybe *MAYBE* as an option but I don't like the idea of leaving something unupdated in a surprising way to the user when yum succeeds w/o an error code. > So yum apparently knows it's installed, why does it mention the error > then ? b/c it's being updated away. pth2.0.0 is being updated away from pth 1.4 - so newpg ( which you have installed) needs pth 1.4 not pth > 1.4 so you end up with a broken dep on newpg. when you update pth 1.4 with pth 2.0 you end up NOT having pth 1.4 - there is the source of the dep problem. -sv
