Debian 3.0 (native/quilt) and the kernel packages
tim.gardner at canonical.com
Thu Aug 5 15:33:24 BST 2010
On 08/05/2010 07:33 AM, Andy Whitcroft wrote:
> At UDS it was decided we should investigate the new Debian source formats
> 3.0 (native) and 3.0 (quilt) to see if there were any advantages for
> the kernel switching to them. The short answer appears to be no at the
> current time. As we use an orig.tar.gz from upstream Linus' tree we would
> need to use 3.0 (quilt) format, and that provides basically no advantage
> for us. Therefore the recommendation is that we stay with the existing
> 1.0 format. To do this we are recommended to explicitly indicate the
> version we are using. I will push a patch to the list shortly to do this.
> A fuller writeup of the pros and cons of these new formats is below.
> = Background =
> The debian archive is switching to a pair of new formats; 3.0 (native)
> and 3.0 (quilt). These are becoming the preferred formats for upload.
> As part of the process soyuz has gained the ability to accept uploads in
> this format. See here for further background:
> == 3.0 (native) ==
> This format is essentially a raw tarball format. However there is no
> support for an orig tarball in this format. The entire contents of the
> source directory excluding the .git directory are picked up, including
> all of the permissions. This would be appropriate for the kernel as
> the resultant build tree is completely identicle to the git checkout.
> This lack of support for an orig tarball renders the format unsuitable
> for the kernel as they are used heavily to reduce upload times.
Given kernel uploader access to infrastructure machines in the DC, I do
not agree that upload times are relevant wrt this format. I've never
been a big fan of orig tarballs because I think it adds an extra level
of complexity (not to mention orig tarball naming assumptions). I would
much rather prep and upload a source package as it exists (minus .git
directory noise), just as we must do for all non-master topic branches.
As I understand it, the 3.0 format also allows for better package
> == 3.0 (quilt) ==
> This format supports an orig tarball and so there are two forms.
> Without an orig tarball the format is essentially identicle to the 3.0
> (native) format. With an orig tarball the source form is made up of two
> tarballs the orig tarball as normal and a second tarball representing
> the debian directory. This second tarball is a clean tarball of the
> debian directory contents. Any quilt patches listed in debian/patches
> are applied to the tree. Finally any delta in the remainder of the tree
> is encoded as a patch in the debian/patches directory. This makes it
> very similar to the current orig+diff format except that permissions and
> empty files are correctly encoded for the debian directory. If we did
> convert over to this format we might want to move the branch specific
> changes into the debian directory, to debian/master for example.
Just say no to quilt.
> = Advantages =
> Permissions would be maintained correctly in the debian directory.
> Also the source as obtained by apt-get source would be more readily
> manipulated as it would already by ready for use with quilt. Other than
> this there is no compelling reason to convert to any of the new formats.
> There does not appear to be any compelling drive to remove the existing
> 1.0 format we are already using.
> = Conversion =
> For our use case we are not going to be able to sensibly turn the patches
> into a quilt set, though there is some work ongoing to provide tooling to
> produce such a quilt stack from git history. So we would most likely make
> use of the automatically created patch mode of the quilt. Conversion is
> as simple as creating debian/source/format containing '3.0 (quilt)'.
> If we do not convert we are advised to specify '1.0' format explicitly.
> = Caveats =
> This functionality was added under Bug:293106, some of the write up
> implies this feature may only be enabled for lucid and later.
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team