Re: Package updating

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

 



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 :)).


--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]