From a5ea919cd9bc80267bb1071b41a90e981ada6032 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Sat, 24 Aug 2013 17:47:07 +0100 Subject: More comprehensive workaround for `3.0 (quilt)'. --- dgit.1 | 70 ++++++++++++++++++++++++++++++++++++------------------------------ 1 file changed, 38 insertions(+), 32 deletions(-) (limited to 'dgit.1') diff --git a/dgit.1 b/dgit.1 index 322bc3b..1abb7ec 100644 --- a/dgit.1 +++ b/dgit.1 @@ -128,12 +128,6 @@ field, runs debsign to sign the upload (.dsc and .changes), pushes the signed tag, and finally uses dput to upload the .changes to the archive. -For a format `3.0 (quilt)' source package, dgit push -may also have to make a commit on your current branch to contain -quilt metadata. It will do this automatically if necessary. -You can explicitly request that dgit do just this -dgit quilt-fixup. - dgit push always uses the package, suite and version specified in the debian/changelog and the .dsc, which must agree. @@ -141,15 +135,12 @@ If dgit push fails while uploading, it is fine to simply retry the dput on the .changes file at your leisure. .TP .B dgit quilt-fixup -Looks to see if there is quilt patch metadata left over by dpkg-source --b, and if so makes a git commit of it. This is normally done -automatically by dgit push. dgit quilt-fixup takes no additional -arguments. Note that it will only process a patch generated by -dpkg-source for the most recent version (according to the -debia/changelog). - -It is not normally necessary to run dgit quilt-fixup explicitly; -where necessary it is done as part of dgit push. +Looks to see if the tree is one which dpkg-source cannot properly +represent. If it isn't, dgit will fix it up for you (in quilt terms, +by making a new debian/ patch containing your unquilty changes) and +make a commit of the changes it has made. + +This is normally done automatically by dgit build and dgit push. .SH WORKFLOW - SIMPLE It is always possible with dgit to clone or fetch a package, make changes in git (using git-commit) on the suite branch @@ -274,15 +265,34 @@ in git and a fast-forwarding release branch; or you could do your work directly in a merging way on the .BI dgit/ suite branches. If you do this you should probably use a `1.0' format -source package. In the archive, the delta between upstream will be -represented in the single Debian patch. - -Secondly, you can regard your quiltish patch stack in the archive as -primary. You will have to use other tools besides dgit to import and -export this patch stack. For `3.0 (quilt)' packages, dgit has to do -more work to work around some braindamage in way dpkg-source handles -changes made to this format. See also the BUGS section. We recommend -against the use of `3.0 (quilt)'. +source package if you can. In the archive, the delta between upstream +will be represented in the single Debian patch. + +Secondly, you can use `3.0 (quilt)', and regard your quiltish patch +stack in the archive as primary. You will have to use other tools +besides dgit to import and export this patch stack. But see below: +.SH FORMAT 3.0 (QUILT) +For a format `3.0 (quilt)' source package, dgit may have to make a +commit on your current branch to contain metadata used by quilt and +dpkg-source. + +This is because (i) the `3.0 (quilt)' source format cannot represent +certain trees, and (ii) packing up a tree in `3.0 (quilt)' and then +unpacking it does not always yield the same tree. Instead, +dpkg-source insists on the trees having extra quilty metadata and +patch files in the debian/ and .pc/ directories, which dpkg-source +sometimes modifies. + +dgit will automatically work around this braindamage for you when +building and pushing. The only thing you need to know is that dgit +build, sbuild, etc., may make a new commit on your HEAD. If you're +not a quilt user this commit won't contain any changes to files you +care about. + +You can explicitly request that dgit do just this fixup, by running +dgit quilt-fixup. + +We recommend against the use of `3.0 (quilt)'. .SH OPTIONS .TP .BR --dry-run | -n @@ -513,14 +523,10 @@ the .orig.tar.gz could be transported via the git repo as git tags. Doing this is made more complicated by the possibility of a `3.0 (quilt)' package with multiple .orig tarballs. -`3.0 (quilt)' packages have an additional difficulty: if these are -edited in the most normal way, and then fed to dpkg-buildpackage, -dpkg-source will add extra quilt patch metadata to the source tree -during the source package build. This extra metadata is then of -course not included in the git history. So dgit push needs to commit -it for you, to make sure that the git history and archive contents are -identical. That this is necessary is a bug in the `3.0 (quilt)' -format. +dgit's build functions, and dgit push, should not make any changes to +your current HEAD. Sadly this is necessary for packages in the `3.0 +(quilt)' source format. This is ultimately due to design problems in +quilt and dpkg-source. There should be an option which arranges for the `3.0 (quilt)' autocommit to not appear on your HEAD, but instead only in the -- cgit v1.2.3