[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[kad@gmx.de: debian binary diff system ?!]


only want to forward this mail to debian-cd because it might be interesting
to the other package manager developers (like apt, dselect, .. developers.)


----- Forwarded message from Kai Duebbert <kad@gmx.de> -----

X-Envelope-Sender: kad@gmx.de
From: Kai Duebbert <kad@gmx.de>
To: debian-devel@lists.debian.org
Subject: debian binary diff system ?!
Date: Sat, 14 Nov 1998 14:05:24 +0100


I was wondering if anybody is working on something like making binary diff
updates possible with debian!? It always bugs me again, when I have to download
a whole package (and pay the German telephone fees...), although just something
in the documentation or so is changed. and i like to have an up-to-date system.

If nobody is working on that, did you already discuss something like this
before? How do others think about this? Anybody interested to work on this?

The system I thought of is the following.

on a debian server:

1. create a new directory in each directory (e.g. base/diffs,
devel/diffs).... Maybe something else. 

2. Have a script running (on the server), that always when
a new package arrives extracts it, puts the debian control files etc. in the
new diff, compares (e.g. with xdelta) the binary files of the version before to
the new version and puts the generated .xd files in the new diff as well.

3. the new package stays in the normal directory, the old one gets deleted
(just like on the normal debian server) and e.g. the oldest diff file, so there
are about 3 (or more?) diffs in the diff directory.

on the client system:

1. dselect (or the new apt?) gets the up-to-date packages list of the server.

2. user (who uses the new "diff-method") just selects what packages he wants to
update as usual and goes on [install]

3. before connecting to the server, "diff-method" examines what packages are
	+ if the new to install package is a new upstream version (not just an
	   new internal maintainer version), it decides to get the
	  whole package (or not??).
 	+ if the new to install package is an internal
	  maintainer version, it checks how old the installed package
	  is and if its not older than 3 (or more?) versions, it
	  decides to get the diff files it needs to  update the local
	  binaries to the newest version, otherwise if the installed
                version is too old to be updated by diff, it gets the
	  whole package new. 	
	+ user can tell if he wants the whole package not the diffs 	
	+ maintainers can mark certain important packages to be downloaded as 
	  whole packages only (e.g. glibc etc.)

4. "diff-method" connects to the debian server (which hopefully has
also the new diff files)

5. getting the new files as decided before (maybe checks if the diffs it needs
to get are not bigger than the whole package, if so it gets the whole package
instead of the diffs)

6. applying the diffs or just installing the new package.

obviously there is still loads to solve first. 

- reduces the costs
- reduces bandwidth usage
- easy to have an always up-to-date system (good for security reasons?)
- no manpower for administration needed (well, hopefully....)
- package maintainers dont have to worry if they are just changing a typo in
the changelog...... ;) 
- could also be done for other systems (rpm, slp, etc.)
- wouldnt interfere with the other methods and servers could decide if they
want this system or not
- only advantages for user

- more diskspace usage on debian servers
- more cpu usage on debian servers
- ?

ideas are welcome. any objections? please give feedback as I want to start it
quite soon, if nothing important stands against it.


Kai Duebbert
e-Mail: kad@gmx.de , duebbert@informatik.tu-muenchen.de

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

----- End forwarded message -----

  Vienna Backbone Service - we support experimental data transfer technology
                    Registered Linux User #62222 (GP3078)

Reply to: