[Mageia-discuss] Suggestions for the ISO
andr55 at laposte.net
Sat Nov 6 19:58:11 CET 2010
Olivier Thauvin a écrit :
> * andre999 (andr55 at laposte.net) wrote:
>>> * andre999 (andr55 at laposte.net) 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
> That mean people udapting frequently their distribution will not profit
> of delta rpm, then downloading the full rpm as soon they made one
> 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).
>>> 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
> 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.
More information about the Mageia-discuss