Debian 3.0 (native/quilt) and the kernel packages

Stefan Bader stefan.bader at canonical.com
Thu Aug 5 14:41:03 UTC 2010


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.

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





More information about the kernel-team mailing list