Debian 3.0 (native/quilt) and the kernel packages
apw at canonical.com
Thu Aug 5 16:11:27 UTC 2010
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.
> > 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.
More information about the kernel-team