On Tue, 2007-03-27 at 08:26 -0400, seth vidal wrote: > On Tue, 2007-03-27 at 13:29 +0300, Jonathan Dieter wrote: > > And I changed Presto last night to use the full method, rather than the > > fast method. Our fallback method is pretty lousy (exiting with an > > error, working the second time yum is called), at least for the moment. > > > > Why is that? I need to take a look at the code but there doesn't seem to > be any reason why it shouldn't be able to fall back to downloading the > whole package. It knows where it is. > > -sv > You're obviously the expert in yum, so most of this will be obvious, and I'd definitely appreciate correction on anything I have wrong. I'm going to summarize the steps yum takes and mark how presto interacts with *: 1. Yum gets repomd for each repository - postreposetup_hook called 2. *Presto gets prestomd for each repository (the format of which is cunningly stolen from yum). ;) 3. *Presto gets presto.xml.gz for each presto repository (once again using very slightly modified python code). - end of postreposetup_hook 4. Yum gets primary.xml.gz for each repository. 5. Yum finds what packages are going to be update/installed/removed, resolves dependencies and sets up a transaction. - postresolve_hook called 6. *Presto cycles through packages, sees which are to be installed (like kernel) or updated, and checks for available drpms. 7. *If there is an available drpm, presto then uses applydeltarpm -s to see if the drpm can be applied correctly. 8. *If the drpm can be applied correctly, presto modifies the package information in the transaction sack so that it points to the drpm (storing the original information elsewhere in the PackageObject). - end of postresolve_hook 9. Yum downloads rpms (and drpms where they've been substituted in). - postdownload_hook called 10. *Presto cycles through drpms downloaded and generates rpms from the drpms. It will exit at this point if it is unable to generate the rpm. 11. *Presto reverts all information that it changed in the PackageObject. - end of postdownload_hook 11. Yum installs rpms - posttrans_hook called 12. *Presto displays and logs savings information - end of posttrans_hook 13. Yum exits I chose to leave the heavy lifting of step 9 to yum because it seemed the most elegant solution. However that does leave us with a nasty exit if we are unable to reconstruct the rpms. Two possible solutions: 1. Write a subclass of PackageObject with verifyLocalPackage overloaded to reconstruct the rpm and fail if we are unable to (not sure if this is very feasible or even a good idea). 2. Create a predownload_hook that does step 9, and then let yum download the full package if it fails. Thoughts, comments, hard objects to be thrown at me for lousy design decisions? ;) Jonathan
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
