Tweak the list of 3rd-party rsync versions.
[rsync-web.git] / rsync-and-debian / rsync-and-debian.sgml
1 <!doctype linuxdoc system>
2 <linuxdoc>
3   <article>
4     <titlepag>
5       <title>About integration of rsync and Debian</title>
6       <author>
7         <name>Martin Pool <tt>mbp@samba.org</tt></name>
8       </author>
9       <date>$Date: 2002/05/14 03:10:09 $</date>
10     </titlepag>
11     
12     <toc>
13     
14     <sect>
15       <heading>Introduction</heading>
16
17       <p>
18         It seems like there is an rsync thread on <tt/debian-devel/
19         every month or two.  Rather than going round in circles yet
20         again, I though I would summarise the issues in one place.
21       </p>
22
23       <p>
24         By way of background, I have been the maintainer of rsync for
25         about a year, and I wrote the <tt/librsync/ and <tt/rproxy/
26         packages.  Incidentally, I run Debian on most of the machines
27         I use, so I do care about the two projects working together
28         well.
29       </p>
30
31       <p>
32         I have tried to respond to all the issues raised on the list
33         recently, but possibly have missed some.  After putting many
34         hours into rsync I suppose I am quite fond of it and may be a
35         little biased, but I think I also know its strengths and
36         problems more than most.
37       
38       <p>
39         If there are issues ommitted by this document, or if you think
40         the answers are incomplete, unbalanced, or incorrect, then
41         please mail <tt/mbp@samba.org/, <tt/rsync@lists.samba.org/
42         and/or <tt/debian-devel@lists.debian.org/.
43
44     </sect>
45
46
47     <sect>
48       <heading>Background</heading>
49
50       
51       <sect1>
52         <heading>The rsync algorithm</heading>
53
54         <p>
55           rsync is really two independent but related ideas: the
56           <em/rsync algorithm/ for delta compression, and its
57           implementation in a mirroring program.
58         </p>
59         
60         <p>
61           The rsync algorithm is described in detail in the ANU
62           Technical Report included with the distribution and on the
63           <htmlurl url="http://rsync.samba.org/" name="rsync.samba.org"> web site.
64           </p>
65
66         <p>
67           Briefly, the rsync algorithm provides an efficient means to
68           transfer a file <em/A/ from a source machine to a
69           destination machine, when a similar file <em/A'/ is already
70           present on the destination.  The destination machine sends a
71           checksum of each consecutive block (of say 1kB) from <em/A'/
72           to the source machine.  The source machine searches through
73           <em/A/ for matching blocks.  Whatever does not match must be
74           different, and a description of these differences is sent to
75           the destination.
76         </p>
77
78         <p>
79           The algorithm could be embodied in other forms and uses than
80           the rsync program.  Indeed, the algorithm has been
81           reimplemented in programs other than rsync itself: in other
82           languages (Rexx, CAML, Java), in a C library (<tt/librsync/)
83           and a derivative in xdelta.  xdelta is a specialization of
84           the algorithm for the case where the two files are local and
85           can be directly compared to compute a minimal binary delta.
86         </p>
87
88         <p>
89           rsync deltas are much more efficient than diffs, for several
90           reasons: most importantly, useful diff formats include
91           context lines, which are wasted information.  rsync gets the
92           same benefit of making sure that the change is applied to a
93           compatible version of the file, but in a much more efficient
94           way.  diffs suffer from being human-readable and therefore
95           verbose, and cannot handle binary files.  Both can be
96           transparently compressed.  diffs are an invaluable tool for
97           software development, but not ideal for distribution of
98           deltas.
99         </p>
100       </sect1>
101
102
103       
104       <sect1>
105         <heading/The rsync program/
106
107         <p>
108           The rsync mirroring program is similar in functionality to
109           other tools such as <tt/wget/, <tt/ftpmirror/, <tt/cvsup/
110           and <tt/rdist/.  It has a number of functions that are
111           useful in association with file mirroring, such as bandwidth
112           limiting, access control, recursive mirroring, and selection
113           of files to copy in various ways.
114         </p>
115
116         <p>
117           In general, rsync is substantially faster than other
118           tools, because it uses delta compression, and because the
119           protocol is designed to be efficient both in traffic and
120           round trips.  rsync can use <tt/zlib/ to compress traffic
121           (and introduce double-<tt/free()/ security holes :-), at the
122           option of the client.  Compression may also be disabled by
123           the server administrator.
124         </p>
125
126         <p>
127           rsync has the important property that it is generally
128           idempotent: repeated runs of rsync, even if interrupted,
129           make the contents of the destination machine converge
130           towards those of the source machine.
131
132         <p>
133           Unlike wget and ftpmirror, rsync must be installed on both
134           the client and the server.  It uses its own protocol, rather
135           than HTTP or FTP.  This is probably the biggest practical
136           drawback at the moment: one cannot use rsync from arbitrary
137           web sites, but only from systems  that have specifically
138           chosen to support it.  On the other hand, many important
139           sites for free software do now support rsync, and the
140           developers see them as an important constituency to support.
141
142         <p>
143           rsync can tunnel through a proxy server that supports
144           <tt/HTTP CONNECT/, a SOCKS server (using <tt/socksify/), an
145           ssh tunnel, or various other methods.
146
147         <p>
148           rsync can run as a daemon, similar to an <tt/ftpd/, in which
149           it is controlled by the <tt>/etc/rsyncd.conf</tt> file.  The
150           archetypal use is to offer public, anonymous, read-only
151           access to a software archive but as with <tt/ftpd/ other
152           configurations are possible and common.
153         </p>
154
155         <p>
156           rsync can also run across a tunnel program such as <tt/ssh/,
157           in which case it is very similar to <tt/scp/.  This mode is
158           commonly used for making network backups, or uploading
159           information to a web server.
160         </p>
161         
162         <p>
163           rsync may also be used locally, which is a degenerate case
164           with client and server connected across a unix-domain or
165           localhost socket.
166         </>
167
168         <p>
169           rsync runs on many varieties of Unix under both gcc and
170           native compilers, and also under Cygwin on Microsoft
171           platforms.  There is somebody working on a VMS port.
172         </p>
173       </sect1>
174
175
176       
177
178       <sect1>
179         <heading/librsync/
180
181         <p>
182           <tt/librsync/ is a library that reimplements the rsync
183           algorithm in a very flexible way, with the goal of allowing
184           any reasonable mode of operation, and integration with any
185           existing program.  rsync does not currently link to
186           librsync, but it might do so in the long term.
187
188         <p>
189           <tt/librsync/ currently uses an encoding
190           format different to that of rsync 2.5, mostly because I did
191           not want to be constrained by historical code.
192
193         <p>
194           <tt/librsync/ is at version 0.9.5 and roughly as stable as
195           the version number suggests: it is used by Intermezzo and
196           some other projects, but is not yet really mature.  The
197           <tt/librsync/ distribution comes with a tool <tt/rdiff/ that
198           exposes the functionality as a Unix tool to shell scripts,
199           etc.  <tt/librsync/ is LGPL'd.
200
201         <p>
202           For example, you can imagine the server calculating and
203           caching the checksums, or the client calculating the delta
204           once and then sending it over UDP multicast to several
205           destinations, or uuencoded in email.  Neither of these would
206           be straightforward to implement in the rsync codebase, but
207           all can be done with rdiff.
208
209       </sect1>
210
211
212       <sect1>
213         <heading/rproxy/
214
215         <p>
216           <tt/librsync/ is used in the <url
217           url="http://rproxy.samba.org/" name="rproxy"> program, which
218           is a prototype of transparent integration of delta
219           compression into HTTP.
220         </p>
221
222         <p>
223           rproxy implements delta compression of arbitrary HTTP
224           content, whether dynamic or static.  For example, rproxy
225           gives very good compression on repeated visits to portal
226           sites such as Slashdot, since it can transmit only the
227           sections of the page modified since last time it was
228           viewed.  Regular HTTP caches, by contrast, must either hit
229           on the whole page, or reload the whole page, and therefore
230           do poorly on template-based dynamic content.
231
232         <p>
233           rproxy adds compatible extensions to HTTP headers, and can
234           pass through HTTP caches.  It requires upstream and
235           downstream support, which at the moment means two
236           installations of rproxy, but in the future could conceivably
237           be integrated into Mozilla, Squid, Apache and similar
238           programs.  
239
240         <p>
241           rproxy is packaged in Debian and is moderately useful for
242           people with slow links.
243
244         <p>
245           rproxy is not HTML-specific, but HTML is by far the most
246           common case of dynamic HTTP content that can be
247           delta-compressed.  However, HTML documents tend to be fairly
248           small, and as connectivity improves they're becoming of
249           decreasing interest as a compression problem.
250
251         <p>
252           (My personal interest in this project declined significantly
253           when I went from a 56k6 modem to ADSL at home.  I realize
254           many people in the world still have slow connections.)
255
256         <p>
257           There are some Internet Drafts from Jeffrey Mogul and others
258           that add similar delta compression based on the server
259           storing all possible deltas.  Last time I looked, there did
260           not seem much interest in wide adoption of these proposals.
261
262         <p>
263           Documenting a protocol extension to the standard expected by
264           an RFC can be a lot of work.  A beginning on this work has
265           been made for rproxy, but more experiments with the
266           implementation are needed before proposal as a standard.
267
268         <p>
269           rproxy is not being actively developed at the moment.
270           Obviously I cannot answer why every programmer in the world
271           does not work on this.  Personally I think that developing
272           rsync itself, and then librsync/rdiff, is likely to be more
273           useful; I suspect other people interested in working in this
274           area might have similar thoughts.  
275
276         <p>
277           I don't think there are any problems in the code or project
278           that would actively prevent anybody from working on it.  I'd
279           be happy to hand over maintenance to somebody else.  Ben
280           Elliston has expressed interest in looking after it in the
281           last couple of months, and possibly it will be more active
282           in the future.
283       </sect1>
284
285       
286
287       <sect1>
288         <heading>Introduction to Debian</heading>
289
290         <p>
291           Debian is a free operating system developed by the
292           cooperation of people all over the world.  The most
293           important relation of rsync to Debian is copying of software
294           packages from developers to distribution servers to end
295           users.
296         </p>
297
298         <p>
299           Many Debian users get their software by internet download
300           from a public server, rather than pre-installed on a machine
301           or on CD-ROM.
302         </p>
303
304         <p>
305           Debian software archives include both software source,
306           binary packages for various architectures, and index
307           metadata, primarily the <tt/Packages/ files.
308         </p>
309
310         <p>
311           Because of Debian's community development process, new
312           packages are released very often.  On a typical day in
313           Debian's <tt/unstable/ release, there might be fifty new
314           uploads.
315         </p>
316
317         <p>
318           Debian is quite different from other software distributions
319           in shipping so many packages so frequently.  The BSDs (as I
320           understand it) base most of their development out of a CVS
321           or CVSup tree, which inherently distributes coarse-grained
322           deltas.  Proprietary systems make binary releases, but much
323           less frequently.  Possibly the development branches of other
324           distributions, such as Redhat "Rawhide" and Mandrake
325           "Cooker" are similar.
326           </p>
327       </sect1>
328
329
330
331
332       <sect1>
333         <heading>apt-proxy</heading> 
334       <p><label id="apt-proxy">
335         <url url="http://apt-proxy.sourceforge.net/" name="apt-proxy">  is a caching proxy for Debian archives.  It appears as an HTTP
336         server to apt clients, and uses rsync, http, or ftp to connect
337         to an upstream server.  
338
339       <p>
340         Because rsync is less efficient than HTTP for transferring
341         compressed files, <tt/apt-proxy/ can selectively use rsync for
342         uncompressed Packages and files and HTTP or FTP for <tt/.deb/
343         files.
344
345       <p>
346         <tt/apt-proxy/, unlike Squid, has domain knowledge about
347         Debian archives and can therefore perform functions such as
348         purging old packages from the cache.
349
350       <p>
351         The original apt-proxy was written by Paul 'Rusty' Russel.
352         The current maintainer is Chris Halls.
353       </p>
354     </sect1>
355   </sect>      
356
357     
358
359     <sect>
360       <heading>Open Issues</heading>
361
362
363       <sect1>
364         <heading/Compressed files cannot be differenced/
365
366         <p>
367           <tt/gzip/, like most compression algorithms has the property
368           that a change in the source file at one point will cause
369           cascading changes in the output file from that point
370           onwards, and therefore make delta compression more or less
371           useless.
372         </p>
373
374         <p>
375           Although delta compression is not possible, rsync is still a
376           very useful tool for mirroring compressed files.  The
377           efficient network protocol mean that it will generally be
378           slightly faster and use less traffic than HTTP or FTP.
379
380         <p>
381           There is a patch called <tt/--rsyncable/ for gzip that fixes
382           this behaviour: gzip files are basically broken up into
383           blocks so that changes (including insertion or deletion) in
384           the input file affect only the corresponding blocks in the
385           output file.  (The blocks are not of fixed size, but rather
386           delimited by marker patterns at which a checksum hits a
387           particular value, so they move as data is inserted or
388           removed.)
389
390         <p>
391           I believe that this will merge into the upstream <tt/zlib/
392           soon and be on by default, at which point <tt/.deb/ files
393           will delta-compress well.  This patch does seem to be
394           languishing, though, and it would be good to either get it
395           into the upstream, or into Debian's own version.  Needless
396           to say it must be extremely thoroughly tested.
397
398         <p>
399           The scheme for containing changes is not specific to rsync,
400           and might also be useful with <tt/xdelta/, <tt/rdiff/, or
401           some other binary delta scheme invented in the future.  It
402           also does not require a copy of the old file when
403           compressing the new one.
404
405         <p>
406           This scheme relies on the output file being determined only
407           by the input file.  As far as I know compression schemes
408           like gzip, lzw, and bzip2 are deterministic in this way.
409           (GnuPG, for example, is not, since it uses a random session
410           key.)
411
412         <p>
413           Incidentally this would allow more efficient deltas between
414           Debian ISO images.
415         </p>
416
417         <p>
418           Alternatively, you could distribute an uncompressed package
419           tree that would rsync efficiently, but since the gzip patch
420           should merge soon this seems unnecessary.
421
422         <p>
423           There is also the interesting possibility of using
424           <tt/dpkg-repack/ to generate something similar to the
425           previous <tt/.deb/ and then use it as the basis of an rsync
426           download.
427
428         <p>
429           It could be possible to make an equivalent patch to
430           <tt/bzip2/, but possibly the large block size would cause
431           trouble.
432
433         <p>
434           A patch to gzip which implements this behaviour is available
435           from rsync CVS.
436       </sect1>
437
438
439
440       <sect1>
441         <heading/rsync is too hard on servers/
442
443         <p>
444           If it is, then I think we should fix the problems, rather
445           than invent a new system from scratch.  I think the
446           scalability problems are accidents of the current codebase,
447           rather than anything inherent in the design.
448         </p>
449       </sect1>
450
451
452       
453       <sect1>
454         <heading/We should throw out the current code and start from
455         scratch/
456
457         <p>
458           Some projects (Apache 2.0, Mozilla, ...) choose to do this;
459           some concentrate on piecemeal improvement (Linux).
460
461         <p>
462           As Joel Spolsky recently observed, throwing the code out to
463           start from scratch always seems like a nice idea, but rarely
464           works out.  Essentially you are opting for the devil you
465           don't know, but he definitely exists.
466
467         <p>
468           Having dealt with some fairly crufty old code I sometimes
469           feel like doing this in rsync, but I can also see the
470           arguments against it.  Starting from a new codebase would
471           bring in plenty of new bugs (including security bugs),
472           orphan existing users, and halt progress until it caught up
473           to the same level.  It would require carefully documenting
474           all the existing internal protocols and behaviours, which is
475           a nice idea but not clearly a good use of the developers'
476           time.
477
478         <p>
479           If you throw out the code, you have the questions of whether
480           or not to keep the current network protocol, and whether or
481           not to keep the current command-line option.
482
483         <p>
484           Not being able to talk to old remote versions would be a
485           real pain, and would certainly slow adoption.  (Think of how
486           unpopular SSH2 was when it wanted to be incompatible with
487           SSH1, but use the same TCP port.)  On the other hand,
488           keeping the same network protocol limits your ability to
489           redesign things.
490
491         
492         <p>
493           There is some cruft in the command line syntax, but throwing
494           it out would also break everybody's scripts, mental maps,
495           and documentation.
496
497
498         <p>
499           Possibly rsync 3.0 will be largely rewritten.  <tt/librsync/
500           is a start in that direction.  If you want to do this,
501           <tt/librsync/ might help you, but please think about it
502           before you begin hacking.
503
504       </sect1>
505
506       
507
508
509       <sect1>
510         <heading/rsync development roadmap/
511
512         <p>
513           Debian's goals for rsync have to be balanced against the
514           requirements of other users (including the mirror sites that
515           distribute Debian) and the limited development resources.
516
517         <p>
518           As of April 2002, the 2.5.5 release is current and 2.5.6 is
519           pending.  These versions seem to work quite well and we
520           encourage people to upgrade from stable 2.4.6 and previous
521           versions.  It is very important to the developers to
522           establish a stable base release before starting out on new
523           development.
524         </p>
525
526         <p>
527           A number of enhancements are planned for the 2.6 series.
528           Some of them are discussed below, and more details can be
529           found in the <tt/TODO/ file in the rsync distribution.
530
531         <p>
532           If you want rsync to progress faster, the best thing you can
533           do is find reproducible failure cases and report them well,
534           or to help us write a regression test suite.
535
536         <p>
537           Nobody is very actively working on rproxy or librsync as far
538           as I know.  Personally at the moment I feel supporting rsync
539           itself is more useful.
540       </sect1>
541
542
543
544       
545       <sect1>
546         <heading/Goswin Brederlow's proposal to use the reverse rsync
547         algorithm over HTTP Range requests/
548
549         <p>
550           Goswin Brederlow has a nice proposal that allows rsync
551           compression using a regular HTTP server.  It depends only
552           upon rsyncable archives, and development of new client and
553           support programs.
554
555         <p>
556           The idea, as I understand it, is that the checksums for each
557           package should be pre-calculated and stored on the HTTP
558           server along with the files they describe.  (The checksum
559           files should be on the order of a thousand times smaller
560           than the archive file.)
561
562         <p>
563           The client program will download the checksum file over HTTP
564           if it exists.  The client can then search for common blocks
565           in the local file, and therefore determine what new regions
566           it must fetch from the server.  The client then sends an
567           HTTP request using the optional <tt/Range/ header for the
568           relevant sections of the new file, and patches them onto the
569           old file.  The checksum file ought to also include a
570           whole-file message digest which can be used to ensure that
571           reassembly was successful.
572         
573         <p>
574           This scheme has the great advantage that the server is
575           entirely passive, and only needs to support standard HTTP.
576           The checksum files can be generated once for each package
577           either during upload, or by the administrator of a
578           particular server.
579
580         <p>
581           (This is not the same as rproxy, which uses a different
582           encoding and requires upstream support, but can
583           transparently compress any request without requiring
584           signature files on the server.)
585
586         <p>
587           This scheme could be fairly easily built on top of rdiff or
588           librsync.
589
590         <p>
591           I think this sounds like a very promising scheme.  I think
592           rsync might still be better for people who want to copy
593           large trees, but for users apt-getting single packages this
594           would be a simple way to get delta-compression in, pending
595           only --rsyncable files.
596
597
598         <p>
599           I'm not sure if all HTTP servers currently handle <tt/Range/
600           commands efficiently.  This proposal would probably stress
601           them more than is common at the moment.
602
603         <p>
604           Because it requires a special client, and special checksum
605           files stored on the server it has a wider impact than just
606           using rsync.  It ought to be done in a non-Debian-specific
607           way.  Rather than adding knowledge about the deltas into
608           apt-get itself, we ought to make a separate tool which
609           downloads a delta over HTTP.
610
611       </sect1>
612
613
614
615
616        <sect1>
617          <heading>rsync only compares files with the exact same
618            name</heading>
619
620          <p>
621            Even for uncompressed files, rsync will not currently try to
622            use <tt/linux-2.4.17.tar/ to do delta-compression against
623            <tt/linux-2.4.18.tar/, because it cannot guess from the
624            names that the two files are related.
625
626          <p>
627            Paul Russell has contributed a patch which adds a heuristic
628            to detect this.  It will probably be merged in 2.6.
629          </p>
630        </sect1>
631
632
633        <sect1>
634          <heading/rsync uses too much memory/
635
636          <p>
637            rsync traverses the entire directory tree before it begins
638            copying files.  On machines with little virtual memory and a
639            lot of files to copy this can be a problem.
640
641          <p>
642            Some problems in this area have been fixed in the 2.5
643            series.  Other solutions involving internal restructuring of
644            the <tt/flist/ and <tt/hlink/ code will be attempted in 2.6,
645            and they should yield a substantial improvement.
646
647          <p>
648            We are not likely to change the general approach of
649            traversing the tree up-front in the near future, because it
650            is tightly tied to the network protocol.  It might be
651            attempted in the 3.0 timeframe, but it is not entirely clear
652            that it is really a problem.
653        </sect1>
654
655
656
657        <sect1>
658          <heading>rsync hangs?</heading>
659
660          <p>
661            There were a number of deadlock bugs in the past.  We
662            believe they are all fixed in 2.5.5, but would welcome good
663            bug reports to the contrary.  Some of them were in fact
664            Linux and Solaris kernel bugs, but they've been fixed by the
665            relevant parties quite some time ago.
666          </p>
667        </sect1>
668
669
670
671        <sect1>
672          <heading>Reduced network usage is not justified by increased CPU
673            usage
674          </heading>
675
676          <p>
677            The balance point will vary for each administrator.  It is
678            hard to answer this universally.  The balance is very
679            different in countries other than the US.
680          </p>
681
682          <p>
683            I suspect CPU cycles are falling in price faster than
684            network bandwidth, and for many people unused CPU cycles are
685            wasted but network packets cost money.
686          </p>
687        </sect1>
688
689
690
691        <sect1>
692          <heading/rsync can't saturate a fast link/
693
694          <p>
695            rsync with <tt>--whole-file</tt> (to turn off the
696            delta algorithm and be more comparable to ftp) floods a
697            100Mbps link.  If you have something faster than that to
698            your upstream Debian mirror, you're a lucky person.
699          </p>
700
701          <p>
702            It is not inherently impossible to make rsync use
703            <tt>sendfile()</tt> and <tt>mmap()</tt>; it's just that most
704            people don't need them.  (Apache did not use them by default
705            either last time I looked, but that doesn't mean it's not
706            fast enough for most people.)
707          </p>
708        </sect1>
709
710
711
712        <sect1>
713          <heading>rsync is not actively developed</heading>
714
715          <p>
716            This was a pretty fair accusation a year ago, but I don't
717            think it is true anymore.  We have made five releases this
718            year, and the <tt/diff -u/ since 2.4.6, the last version
719            from the previous maintainer, is 38305 lines.
720
721          <p>
722            Mail is answered promptly.  The web site has been revised
723            and cleaned.  We're working on a regression test suite, code
724            cleanup and documentation, and other quality issues.
725
726          <p>
727            I'm the most active developer at the moment, but there are a
728            number of other people with experience in the code who
729            regularly commit changes or send patches.
730
731          <p>
732            The stability expectations of our users require a somewhat
733            disciplined approach to accepting patches, but I don't think
734            that's a bad thing.  The goal is to iterate through
735            <em/freeze/ and <em/flow/ phases similar to the kernel.
736
737          <p>
738            The Debian rsync package maintainer, Phil Hands, has been
739            somewhat inactive, but apparently he's back now.  Colin
740            Walters has been helping out.
741
742          <p>
743            If you have patches that were dropped, please send them
744            through again.
745        </sect1>
746
747
748
749        <sect1>
750          <heading>Servers should cache deltas</heading>
751
752          <p>
753            This also smells like premature optimization.  It might be
754            useful, but it certainly seems less important than some
755            other tasks.
756        </sect1>
757
758
759
760        <sect1>
761          <heading>Possible patent on rsync?</heading>
762
763          <p>
764            It has been suggested that some uses of rsync may conflict
765            with a US patent.  I am not sure of the current situation so
766            I won't comment.  I don't know of any suggestion that the
767            rsync program as it currently exists infringes any patent.
768          </p>
769
770          <p>
771            I do know that rsync has been in use for many years by large
772            and small organization with no complaints of patent
773            infringement.
774          </p>
775
776          <p>
777            I would point out that linked lists, mark-and-copy garbage
778            collection, and the Tab key are all patented too.  Somebody
779            who always carefully checked first for software patents
780            would never write anything at all.
781          </p>
782
783        </sect1>
784
785
786        <sect1>
787          <heading>Debian should store more metadata outside of
788          the package file</heading>
789
790          <p>
791            I can see some reasons why this might be a good idea, but
792            it doesn't seem particularly relevant to rsync either way.
793          </p>
794        </sect1>
795
796
797
798        <sect1>
799          <heading>Debian should distribute diffs or xdeltas
800            between different versions of their packages</heading>
801
802          <p>
803            A problem with this is that Debian releases packages very
804            often, and so the number of delta files is large.  This will
805            be a problem for mirror sites who cannot carry all of the
806            delta files for history, although of course the client could
807            fall back to directly fetching the new package if the
808            relevant deltas are not present.
809          </p>
810
811          <p>
812            Fetching a series of deltas which update the same area is
813            less efficient than calculating the deltas directly.
814          </p>
815
816          <p>
817            Although this idea does not seem very practical for people
818            using <em/unstable/, it could work well for <em/stable/
819            and other situations where there are relatively few
820            releases, or for people without network access.  One could,
821            for example, distribute a CD-ROM of xdeltas.  On the other
822            hand, since CD-ROMs are relatively large compared to the
823            distribution it might be simpler to just distribute the new
824            packages directly as is currently done.
825       </sect1>
826       
827       <sect1>
828         <heading>rsync should be used by <tt/apt-get update/</heading>
829         
830         <p>
831           Even if there are few gains from compressing <tt/.deb/s,
832           rsync might help in providing a more efficient transfer of
833           the <tt/Packages/ file, which has small but frequent
834           changes.  This approach is used by <tt/apt-proxy/.
835       </sect1>
836     </sect>
837
838     
839     <appendix>
840     <sect>
841       <heading>Revision history</heading>
842
843       
844 <p><tscreen><verb>
845 $Log: rsync-and-debian.sgml,v $
846 Revision 1.10  2002/05/14 03:10:09  mbp
847 Add note about just transferring Package files.
848
849 Revision 1.9  2002/05/14 02:35:43  mbp
850 Update notes on apt-proxy based on mail from Chris Halls.
851
852 Revision 1.8  2002/04/12 02:04:15  mbp
853 More information about Goswin's idea, as I understand it.
854
855 Revision 1.7  2002/04/12 01:39:52  mbp
856 Lots more details about rproxy.  Thanks to Brian May for prompting me
857 to do this.
858
859 Revision 1.6  2002/04/12 00:43:06  mbp
860 Fix revision history SGML stuff.
861
862 Revision 1.5  2002/04/12 00:24:50  mbp
863 Fix mailing list name.
864 Add revision history.
865         
866           </verb></tscreen></p>
867     </sect>
868   </article>
869 </linuxdoc>