On Thu, Oct 09, 2003 at 08:07:30AM -0400, seth vidal wrote: > > About "update": What happens if the new package requires other > > non-installed packages? Will "update" pull them in? > > yes. it does that now. > [...] > removals will NEVER happen on update/install/upgrade. And this 'foo has > been held back' behavior is not terribly informative to the user. > > In general the 'apt does it this way' argument doesn't go very far w/me. Not an argument for doing it like apt, but I was just trying to understand yum's behaviour in apt's terms. > > Maybe instead have obsoletes unconditionally on and have a switch for > > fault tolerance in obsoletes? E.g. if any obsoletes loop is created > > display the problematic packages to the user for manual intervention, > > remove them for the internal upgrade list and go on with the rest? > > if the loops are large enough it is impossible to see them. Obsolete graphs break down into several continouus and small subgraphs, with most packages living on one-node graphs. In order to find the non-trivial graphs one can start with the packages that do contain "Obsoletes:" (These are 345 out of 1892 packages on a RH9 system with lots of additional repos included, e.g. about 1/6th of the total packages ensemble). Then traverse down the Obsoletes tree to the leaf node for each such package testing whether any new Obsolete: obsoletes the staring package. Even better: A policy to deal with obsoletes when "upgrading" would be to ignore all packages that are being obsoleted by others. A two, three or larger loop would automatically be removed that way resulting in a consistent package pool to opertae with. So in the above scheme while traversing the obsoletes tree yum could remove the packages from its internal ensemble. Does that make sense? -- Axel.Thimm@xxxxxxxxxxxxxxxxxxx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.dulug.duke.edu/pipermail/yum/attachments/20031009/6f28553c/attachment.bin
