(I spoke to Guillem about this at Debconf and promised to write it up
so he could think about it properly at his leisure.)
None of our existing source package formats can reliably
represent
- files which exist upstream but are deleted in Debian
- symlinks and changes to symlinks
- empty files vs. nonexistent files
I would like to propose a format which would address these problems.
It would be more like a successor to 1.0 with diff, than 3.0 (quilt)
is, in that it wouldn't represent a patch stack, merely a tree.
I am tentatively suggesting that this format should be called
`3.0 (rsync)' but I have no strong opinions about the name.
Specification:
A source package in this format contains at least a base orig tarball
P_V.orig.tar.Z and possibly additional orig component tarballs
P_V.orig-COMP.tar.Z.
It also contains an rsync batchfile P_V-R.rsync.Z.
(P = package; V = upstream version; R = revision; Z = compression
extension; COMP = upstream component.)
Extracting:
The orig tarballs are extracted as for `3.0 (quilt)': first the main
orig is extracted into DIR, and then for each COMP, DIR/COMP is
deleted (if it exists) and replaced with the contents of
.orig-COMP.tar.Z.
DIR/debian is not deleted at this stage.
Then, the rsync batchfile is applied with rsync --read-batch. (If the
upstream contained a debian/ directory, the rsync batchfile will
contain the difference between upstream's and Debian's debian/
contents.)
(In all these steps all `dangerous' objects are removed. This
includes symlinks pointing outside the tree, devices, set-id files,
etc.)
Overview of properties of this format:
1.0 1.0 3.0 3.0 3.0
native diff quilt git rsync
Permitted in ftp.d.o Y Y Y - [1]
Provides archive upload/download - Y Y - Y
and storage optimisation.
Permitted in ftp.d.o for packages
with delta from upstream - Y Y - [1] <===
Supports multiple .orig tarballs n/a - Y n/a Y
Can represent any reasonable tree Y - - - Y <===
Supports vcs-based workflow [3] Y Y - Y Y <===
Patch stack represented in ftp.d.o - - Y - -
Supports non-vcs-based workflow (eg
for new upstream version) [2] - Y Y - -
The two features I have marked with `<===' are the key points which
make a new format desirable
Notes
[1] I do not expect any resistance from ftpmaster to supporting this
in dak and ftp.d.o, and permitting it in uploads, modulo the obvious
need for a transition period.
[2] Some people deal with new upstream versions by applying the diffs
from from the last Debian revision of the previous upstream version,
to the orig tarball(s) from the new upstream version. With `3.0
(rsync)' this doesn't work because an rsync batchfile needs to be
applied to an identical tree. Instead, I expect that with `3.0
(rsync)' the full package source code is maintained in a vcs and the
vcs is used to do merges from upstream.
[3] `3.0 (quilt)' requires the delta patch stack to be converted from
vcs commits (if there are vcs commits at all) to a series of patch
files. This causes some difficulties. We have a large number of
tools in Debian to cope with these difficulties.
--
Ian Jackson personal email: <ijack...@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
