[firstname.lastname@example.org: 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 <email@example.com> -----
From: Kai Duebbert <firstname.lastname@example.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.
e-Mail: email@example.com , firstname.lastname@example.org
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
----- End forwarded message -----
Vienna Backbone Service - we support experimental data transfer technology
Registered Linux User #62222 (GP3078)