Hi!
seth vidal wrote:
Okay, I'm losing my mind on this so I'm going to write pseudo-code of
what should be happening for this dep presentation. Everyone who can
understand this, please respond:
- get the list of items in the transaction:
- for installs, check that all the reqs of this install are provided
- for each pkg that provides for it, make sure the pkg is not
being
updated/removed/obsoleted.
- if providing_pkg is being updated/obsoleted: verify that the
updating/obsoleting pkg provides the reqs
- if it does not, mark the req as needed
- if providing_pkg is being removed:
- mark the dep as being needed
- for removes, for each provide of each removing_pkg:
- for each pkg that requires this provide, mark it as needing a
dependency
unless:
- something else provides the dep
- something being installed provides the dep
May be this could be implemented easier if there is a representation of the
rpm db + the delta of currently added/removed pkgs. Then you would just need
to resolve the deps in that db.
- for updates
- break them into install and remove
- for all installs, pass to install
- for all removes pass to delete
If updates are just seen as install and remove information is lost between
these two steps. For smarter handling of multilib situations this
information could be needed. This would allow keeping just one arch
installed. For the kernel this is needed even on single arch systems while
on multilib systems this may be wanted behaviour for all packages.
- for obsoletes
- break them into install and remove
- for all installs, pass to install
- for all removes, pass to remove
I'm not sure I have the case right for updates/obsoletes but looking
through the code it seems to be quasi-sane for matching the sets of
deps/provs.
Obsoletes for "yum update" and "yum update pkg" should probably be handled
differently. The first case should IMHO handle all obsoletes in the given
repositories while the later should just handle the obsoletes for the
updating pkgs.
cu
Florian
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
