3. new debdelta-upgrade service

3.7.1. indexes of debs in APT

Let's start examining the situation for debs and APT. Using indexes for debs is a no-brainer decision: indeed, the client (i.e. the end user) does not know the list of available debs in the server, and, even knowing the current list, cannot foresee the future changes. So indexes provide needed informations: the packages' descriptions, versions, dependencies, etc etc; these info are used by apt and the other frontends.

3.7.2. no indexes of deltas in debdelta

If you then think of deltas, you realize that all requirements above fall. Firstly there is no description and no dependencies for deltas. [1] Of course 'debdelta-upgrade' needs some information to determine if a delta exists, and to download it; but these information are already available:

	      the name of the package P
	      the old version  O
	      the new version  N
	      the architecture A
	    

3.8.1. What "incremental" would be, and why it is not

Please recall Section 3.4. What does not happen currently is what follows: on 3rd Mar , Boe decides to upgrade, and invokes 'debdelta-upgrade'; then 'debdelta-upgrade' finds foobar_1_2_all.debdelta and foobar_2_3_all.debdelta , it uses the foremost to generate foobar_2_all.deb, and in turn it uses this and the second delta to generate foobar_3_all.deb . This is not implemented, and it will not, for the following reasons.

• The delta size is, on average, 40% of the size of the deb (and this is getting worse, for different reasons, see Section 5.2); so two deltas are 80% of the target deb, and this too much.

• It takes time to apply a delta; applying two deltas to produce one deb takes too much time.

• The server does generate the direct delta foobar_1_3_all.debdelta :-) so why making things complex when they are easy? :-)

• Note also that incremental deltas would need some index system to be implemented... indeed, Boe would have no way to know on 3rd Mar that the intermediate version of foobar between "1" and "3" is "2"; but since incremental deltas do not exist, then there is no need to have indexes).

3.9.1. debdeltas_server

This is what is currently used.

3.9.2. debmirror --debmarshal

This is what I used up to 2017 use. It is implemented in the script /usr/share/debdelta/debmirror-marshal-deltas (a simpler version, much primitive but more readable , is /usr/share/debdelta/debmirror-delta-security) I used the complex script that creates deltas for amd64 and i386, and for lenny squeeze sid experimental ; and the simpler one for lenny-security. Let me start outlining how the simple script generate deltas . It is a 3 steps process. Lets say that $secdebmir is the directory containg the mirror of the repository security.debian.org.

1. 	--- 1st step
   	#make copy of current stable-security lists of packages
   	olddists=${TMPDIR:-/tmp}/oldsecdists-`date +'%F_%H-%M-%S'`
   	mkdir $olddists
   	cp -a $secdebmir/dists $olddists
         

2. --- 2nd step call 'debmirror' to update the mirror ; note that I apply a patch to debmirror so that old debs are not deleted , but moved to a /old_deb directory

3. --- 3rd step call 'debdeltas' to generate deltas , from the state of packages in $olddists to the current state in $secdebmir , and also wrt what is in stable. Note that, for any package that was deleted from the archive, then 'debdeltas' will go fishing for it inside /old_deb .

3.9.3. hooks and repository of old_debs

I wrote the scheleton for some commands.

debdelta_repo [--add name version arch filename disttoken]

debdelta_repo [--delta]

debdelta_repo [--sos filename]

TODO that scheleton does not handle 'security', where some old versions of the packages are in a different DISTTOKEN