Package updating

[Bill Crawford]

seth vidal wrote:
> 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
>
>   
Not really ;) we were all hoping you would do it.

But this sounds like the perfect answer to all the "yum wouldn't update 
at all because of dependency problem X" mails we see on the list. 
Getting as much updated as possible in those circumstances would be 
helpful, particularly for people who want to test (whether it be running 
rawhide by default, or trying it from -test1 onwards) -- which I realize 
isn't the case you want to optimize for, of course :)

One point about breaking up transactions: it would allow e.g. a minimal 
install to be done first, thus solving a lot of problems for people who 
get halfway through an install and it breaks due to hardware issues, or 
network problems if doing a net install, or whatever. You'd pretty much 
guarantee that as long as the first (sub?)transaction completed, you'd 
have a bootable system, allowing the rest to be fixed up afterwards 
(and/or reduce the amount of effort involved in restarting the install 
process, by being able to track which partial install transactions 
completed, and restart from the next part). All of which is probably 
even harder than the basis you outlined, but that's the nice thing about 
the future .. there may be a lot of it (hopefully :)).