> But this (as the scripts on the page) f.ex. today upgraded cpp (which pulls > in a lot of gcc-related stuff), and then tries to upgrade those too, one by > one. Ideally, after installing something it should cut down the list of > stuff to install, and if something can't be upgraded don't try the stuff > depending on it. so if there is a cascade of dependencies (a deps b deps c deps d deps e deps f) you're going to pull in most of the packages anyway. What if I told you there was the information in yum's transaction set about those dependencies and that after the initial transaction set was determined you could, if you wanted, break the transaction set up based on those deps into discrete groups of transactions to run? You could - it would mean writing a fair bit of code to: 1. get that information from the ts and figure out where the dep boundaries are 2. store the information on the full set of packages for the total transaction and store where the sub-transaction boundaries exist 3. attempt to depsolve and run each sub-transaction group of packages and record failures/unresolved deps, etc. it's not insurmountable but it's definitely possible. Essentially you could do it in one of two places: 1. do it if there is an unresolvable dependency failure. 2. do it if the transaction set is greater than N packages. Breaking apart large transaction is something we've wanted to do for quite a while it just takes time and some focused thinking to do it correctly. wanna try? -sv -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list