[Mageia-discuss] Suggestions for the ISO

[andre999]

>
> * andre999 (andr55 at laposte.net) wrote:
>    
>> Donald Stewart a écrit :
>>      
>>> On 1 November 2010 10:24, Marc Paré<marc at marcpare.com>   wrote:
>>>
>>>        
>>>> Le 2010-11-01 06:00, Philippe DIDIER a écrit :
>>>>
>>>>
>>>>          
>>> Using delta rpms would reduce the size of the updates, or has my lack
>>> of understanding of delta roms got in the way?
>>>
>>>        
>> Delta rpms, relative to the latest distro release, are long overdue.
>> (And not only in the Mandriva world.  Also for Mozilla, OpenOffice, etc.)
>> Note that for much commercial software, updates are normally delta.
>> Such updates are often erroneously called patches.
>> This may be partly a limitation of rpm packages, or more the programs
>> that install/update such packages.  If so, it should be a priority to
>> correct this lack.
>>      
> 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).
> 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.
> 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.

You are quite likely right about compatibility with current rpm
However we need to enhance the rpm tools (rpmdrake, etc), so I think 
this is good to investigate at the same time.
>    
>> However, the idea of update ISOs is good as well.
>> This could be facilitated by the option of downloading the latest update
>> for each package of the release not already present in the download
>> destination (and preferably removing outdated updates).
>> There is already an option for Rpmdrake to not erase downloaded packages.
>> (Unfortunately one must manually edit a configuration file to select it,
>> but that can easily be corrected.)
>> It also would be useful to have the option to change the download
>> destination.
>> With these changes, creating an update ISO would be only a matter of
>> copying the contents of the update directory to an ISO.
>> Of course, an utility to directly create an update ISO from the
>> repository would be useful, but the advantage of the above approach is
>> that a moderately limited bandwidth user could download updates as
>> produced (that is over an extended period), and produce complete update
>> ISOs for others at any time.
>>      
> 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.

The full updates would still be useful for those who download a package 
for the first time.
But maybe ... if we arrive at a reliable delta update system, it might 
be a good idea -- longer term -- to only use delta updates.  If someone 
installed a new package for which an update existed, the release package 
+ update could be transparently (to the user) downloaded together.
Of course, there are a lot of factors to consider ...
Downloading both would take more bandwidth, but most of the time that 
wouldn't be needed, and the mirrors would save some space (not stocking 
full updates) ...

BTW, regarding is download, I am thinking for a long time we must
provide par2 parity files. It can help low bandwidth to end download.
http://en.wikipedia.org/wiki/Parchive

Thanks for the reference.  That is a really good idea.  Before I got 
slow DSL, that was a big problem.  So it would help a lot of low 
bandwidth users.

my 2 cents :)

- André