Debian 3.0 (native/quilt) and the kernel packages

[Tim Gardner]

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.
>
> -apw
>
> = 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:
>
>      http://wiki.debian.org/Projects/DebSrc3.0
>
> == 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 
compression?

> == 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