Nice work, jbowes!
So we got:
* A script creating deltas between two meta data XML files
* An metadata-parser extension to read these files into the sqlitedb
So we are still missing:
* A script creating the meta meta data (information about the deltas)
* Integration into createrepo to generate deltas automatically and handle
all the data involved.
To be able to this work we need to have an idea how we want to handle the
deltas. I am currently missing the following information to make any useful
decisions:
How often is createrepo called in Fedora and Fedora devel on average?
How many packages do we push into Fedora (updates) and Fedora devel on average?
May be some one who is deeper into the build system can answer that.
(fedora/updates/7/i386 currently contains 2277 pkgs - so that'd be nearly 30
pkgs per day)
I fear we cannot create one delta file per createrepo call. This means we
need to concatenate all delta from a given time period. This shouldn't
require much infrastructure on client side as we can simply apply parts of
the deltas multiple times if we ignore pkgs already present/missing. So we
would just download the deltas back to a time stamp we've already seen.
We could even use a more fine grained splitting for the near past and merge
them to bigger files for the ancient history.
To avoid downloading long lists of deltas over and over again we could just
put the name of the previous delta in every delta. That way the repomd would
just have one entry to the first delta and yum would just follow the chain.
We probably should also put the end of the chain into repomd to give yum a
chance to realize that there is not enough history to catch up and
downloading the whole meta data without downloading the whole useless chain
first.
The single deltas could be named (primary|filelists|other).$TIME.xml.gz.
Any other thoughts on that subject?
Florian
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
