Debian 3.0 (native/quilt) and the kernel packages

[Andy Whitcroft]

On Thu, Aug 05, 2010 at 04:41:03PM +0200, Stefan Bader wrote:
> On 08/05/2010 04:33 PM, Tim Gardner wrote:
> > 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.
> > 
> We have orig tarballs for all topic branches... :) Ok, given the ability to
> upload from the DC speed is probably not the matter. Question would rather be
> are there really advantages from using the 3.0 format. We could get rid of the
> orig tarball just by not doing it.
> 
> Compression would be an argument to conserve archive size.

I seem to remember that the security team were very keen for us to have
orig tarballs.  Something todo with the way their infrastructure works.

> Stefan
> > As I understand it, the 3.0 format also allows for better package 
> > compression?

It allows us to switch the orig tarballs to .bz2 yes.

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

-apw