[Yum] 'yum upgrade' unexpected behaviour

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux