[pacman-dev] delta support in libalpm

[Xavier]

On Mon, Feb 23, 2009 at 12:27 PM, Brendan Hide
<brendan at swiftspirit.co.za> wrote:
>
> This makes a lot more sense to me now. Thank you for the clarification,
> Xavier. It is the most efficient way, end-user-wise, despite the
> possibly-excessive metadata. It isn't necessarily efficient for the server.
> :/
>
> Looking at the logistics, the best time to make the delta is after the new
> .pkg.tar.(gz|bz2) is uploaded to the repo. I assume this is also about the
> time the db is updated. This could be implemented repo-wide as packages are
> updated and delta'd without any individual package maker's direct
> involvement in the delta process - a "passive" change that won't need to
> change anyone's habits.
>
> If you really want to be able to make lots of delta versions, ie, v1tov2,
> v1tov3, v1tov4, v2tov3, v2tov4, v3tov4, then you'd probably have to keep at
> least 4 older (full) versions that will take up a lot of disk space - or
> you'll need to regenerate all the other versions - take up a *lot* of IO /
> RAM / CPU during the generation of the new deltas.
>
> If you only take v1tov2, v2tov3, v3tov4, you only need to keep v4 and the 3
> deltas. When v5 gets uploaded, you create v4tov5 and delete v4 from the
> server thus saving disk space. This is much simpler and more implementable
> than the current "brief".
>
> Mirror servers can mirror the old way - inefficiently - however they should
> mirror the deltas across too. I guess that the mirror servers do a lot less
> bandwidth from the official repository than the end users.
>
> The net result I believe is a much simpler implementation despite achieving
> 99% of the original brief's goal.
>
> Your thoughts?
>

These were my first thoughts, but here is how Garns answered to them :
""
In a previous mail Xavier toyed with the idea to put delta creation
into repo-add, I have given this some thought, as it seems nice in
principle, but there are drawbacks. For Arch this would mean creating
deltas on Gerolde, which seems to be fairly strained already,
according to the dev list. Furthermore this introduces some new
variables to repo-add (at least repo location and an output location)
this would be manageable, but doesn't look very nice.
""
http://www.archlinux.org/pipermail/pacman-dev/2008-November/007672.html