Olivier Thauvin a écrit :
* andre999 ([email protected]) wrote:
* andre999 ([email protected]) wrote:
Donald Stewart a écrit :
The problem of delta rpm is the work need to generated alls delta and
the space need on mirrors to host everything.
We must provide delta for each version to the next one:
- main foo-1
- upd foo-2 D: 1->2
foo-3 D: 2->3 and 1->3 ?
foo-4 D: 3->4 and 1->4, 2->4 ?
I would make all delta updates relative to the distro release, i.e.
- main = foo-1
- upd_full = foo-2, foo-3, foo-4, etc
- upd_delta = foo-1>2, foo-1>3, foo-1>4, etc
without foo 2>3, 2>4, 3>4
(so half as many, with 3 updates.)
Note that the idea is to retain full update packages, the delta updates
being a file-by-file diff of contained files (probably in their own
repository).
That mean people udapting frequently their distribution will not profit
of delta rpm, then downloading the full rpm as soon they made one
update.
Delta rpm will become not so usefull then, except for new install.
Don't think so. I follow closely changes in Mozilla Seamonkey, for
example, and changes are very small with each update. I would say much
less than 1% of the files, by the space taken.
I think that this is typical.
However, for much smaller programs, it could be that after cumulative
updates, the delta update is the same size as a full update - but never
bigger (except maybe a few bytes).
etc...
What if delta 1->4 is bigger than the package itself ? and for 2->4 ?
Highly improbable, as I conceive it.
If foo-1.rpm contains files fooa foob fooc food, and only foob changes
to foob',
then full foo-2.rpm contains files fooa foob' fooc food
and delta foo-2d.rpm contains only file foob', with the info that this
replaces foob.
And of course with this model, there is no 2->4.
Changes between 1->4 will probably be bigger than 2->4 as there is more
changes between them.
Evidently. The deltas will tend to become bigger with each update. But
remaining generally much smaller than a full update.
Delta rpm is hard to manage (any volunteer to write the tools to manage
this ?) and as bonus, I am not sure it is still compatible with our
current rpm...
To create a delta rpm, one only needs the new full version (or the
proposed contents), and a script which automatically includes the new
files with the references to those replaced.
I'm not trying to say it is simple to write - especially since I
understand that the current tools are written in Perl - which has a
syntax which I barely understand.
But I'd be interested in contributing to my ability.
Nothing deny you to start to work on this and then submit you code. It's
what I did for the mirrors tools :)
Good idea :)
The arrival of Mageia is motivating me to contribute more, something
I've always put off doing with Mandriva (except to Bugzilla and forums).
Maybe I can find a language a bit more friendly (to me) than Perl ?
We'll see when BS and SVN will be ready to merge it if it works.
Just think we don't have an infinite space on mirror. Even the sound
good, please try to estimated the cost it can be per release.
I agree it would take more space on mirrors, but as full updates take
much less space than the release,
delta updates would take considerably less space the full updates.
Also, the lower bandwidth to download for users would also benefit the
mirrors.
You know, most of our rpms are less than 10MB, but du -sh is clear, the
distribution is around 35GB per arch.
Nothing is really big on mirrors, but the results is.
But if we can reduce 10MB updates to 1MB, that would be a big benefit
for downloading updates. Especially for low bandwidth users.
And I think that the % update will likely be much more than that.
Don't forget that commercial updates (often erroneously referred to as
patches) are often delta (by file) updates, as being proposed.
- André
