Xavier schrieb:
On Wed, Sep 16, 2009 at 5:40 PM, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] <mad@wol.de> wrote:
Actually first i got confused as repo-remove is documented to take a pkgname as param to remove the whole package (including deltas) from the repo. To use the deltapackage-filename as option to remove only that delta doesn't fitted well into that documentation. I'll try to add this to the man page and usage outputs during my work on this topic...
Right, a separate patch for improving the doc would be nice.
I'd like to add a -d|--delta option to repo-add to create the delta between the current package and the one to be added.
see attached patch (6 months old :P)
I don't think I ever proposed it. I am not sure why. Probably because I don't know how repo maintainers want to use delta ...
Nice, i would use it ;o)
I've also thought about adding a -c|--cleanup option to repo-add and repo-remove that would delete unused files from the repo directory. If booth -d and -c are given than it should remove the "unused" deltas from the repo also and remove the corresponding files.
But as i'm unsure if adding on option to do automatic removal of package files is really a good idea for upstream in the first place, i think i'll do a combined creation, adding and cleanup of "unused" deltas task with -d param for repo-add first.
How do you plan do cleanup delta ?
it's pacman who would know the best which deltas it will never use. I was thinking about refactoring/extending the delta code to expose a public functions which would return a list of unused delta for a given repo or something. Otherwise we need to re-implement / duplicate delta code in pacman. Or did you have a simpler alternative in mind ?
I plan to do it based on the accumulated filesize of all deltas that could be chained together from the repo package version without gaps. As long as this accumulated size is smaller than eg. 90% of the repo packages size (as Allan mentioned that pacmans logic was based on that in the other mail) the delta will be kept. It would make sense to use a recursion based implementation. A function with two params: $1: version we want to chain down from $2: accumulated size in bytes of deltas above us in the chain first call would look like: function currents-package-version 0 inside of function we read all source-versions and filesizes of deltas containing "_to_${1}" in the filename and call function for each match with the source-version and the filesize+$2. We check every recursions retval. If we get a 0 retval for a delta, we would add it to the next repo archive. We return 1 if $2 is larger than repo packages filesize*0.9. Last thing in this function would be a "return 0". This would walk down the chain as far as it could and then on its way returning up to the first caller it will add the appropriate deltas to the repo. If there are deltas in the old repo that can't be chained to other deltas and don't have the repo package version as target get removed as they will not be found by the recursion. But i didn't read through the current code in repo-add or pacmans code for the incremental delta handling so far, so this is a very early draft of how i would do it and i could be very far out in the woods with it... :-D OT: we could also add a configure option to select the maximum percentage we want to use incremental deltas... Marc