Debian 3.0 (native/quilt) and the kernel packages

[Andy Whitcroft]

On Thu, Aug 05, 2010 at 10:44:34AM -0400, Chase Douglas wrote:
> On Thu, 2010-08-05 at 14:33 +0100, 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.
> > 
> > == 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.
> > 
> > = 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.
> 
> I'm not really seeing any disadvantages to this approach, so why is it
> not recommended? Even though it's the "quilt" format, we would not be
> explicitly using quilt. It would just create one big patch every time
> you build the source package, and that patch would be the only "quilted"
> patch.
> 
> The other thing that may be worth looking into is "3.0 (git)" format:
> 
> http://wiki.debian.org/GitSrc
> 
> I think it may be a project that hasn't been completed yet, but it may
> be the real end goal we are after.

I am seeing little advantage to this form, we would need to change the way
we work slightly (different files are generated etc), for what is a minor
gain in size.  Its not like we would have a huge gain in functionality
from any switch.  Therefore I am leaning to not doing anything, especially
as we may end up with different formats in different releases.

I am open to being convinced.

-apw