On Mon, Apr 07, 2003 at 16:59:05PM -0400, seth vidal wrote:
>> 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.
ok I see.
>> 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.
ok.
>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.
Something that would ease the problem for me/other naive users :-) :
print the issue in layman terms. (just some more verbosity actually)
normal:
package newpg needs libpth.so.14 (not provided)
verbose:
package newpg needs libpth.so.14 (which is obsoleted)
Therefore I can not install newpg, since it will be broken after
transition, and since I'm designed not to break your install I'll quit
now.
Possible fixes:
- exclude {PROVIDER OF libpth.so.14}
- remove newpg.
--end--
It can be argumented that should be the task of a frontent (eg. a gui)
so I don't know if this is a good idea.
>> 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.
You are right, you should not upgrade _INTO_ a broken state. But I (as a
user) want to be able to upgrade everything else, everything that's not
in the depends/provides tree of newpg/libpth.
Maybe an option that 'leaves the soon to be broken stuff' alone would be
nice.
As you said on IRC, I could use an exclude, but given this behaviour a
broken package in a repository would -always- stop an upgrade. It's a
very farfetched 'denial of service'. And I (again as a user) would be
adding things to the yum.conf and subsequently I would forget to remove
them.. or I would have to use trial and error... etc.
>> 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.
thanks, It's way more clear now.
,regards
-koeraad.
