On Mon, 2007-06-18 at 18:11 -0400, Jeremy Katz wrote: > Yeah, this is definitely something we want to start looking at. The > question is where in the process does it make sense to generate the > deltas. Do we do them in the build system (the koji level)? Do we do > them in the update system?[1] Do we do them at tree compose (mash) > time? Each has tradeoffs... not sure which is really the best. I'm > pretty sure whichever route we go, we need to go with something that > preserves the deltas and likely at least stores them in the koji store > (with info about them in the kojidb). Perhaps similar to how signing > works? I would probably suggest running the script to generated the deltarpms on a per-package basis rather than a per-repo basis. The reason for this is that the script reads in information about *all* the rpms and deltarpms available, which can take a large amount of time if you're talking about a full repository. I don't know enough about our build system to know where exactly this should go. > At the same time, I think we should sit down and look at how presto is > doing things on the yum side to simplify things a bit. I think that if > we get rid of the concept of a separate standalone delta repository, we > can just make it so that there's a (simpler) XML file to parse with the > delta information and then just add it to the repodata with > modifyrepo[2]. Then, we can also get rid of the duplication of repo > code presented by the PrestoRepository class. I've been trying to get > to mocking something up, but keep having other things come up and steal > time instead. Hopefully tonight/tomorrow... At the moment, code is in place so that a delta repo added via updaterepo will be read via yum-presto without needing the whole concept of a "separate" presto repository. If you can simplify (or remove) much of the code in the PrestoRepository class, that would be brilliant. On a side note, the presto.xml.gz file is in a form such that it could easily be merged with updates.xml.gz. Not sure if that's the route we want to go. 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
