Hi, On Fri, 23 Aug 2013, Ian Jackson wrote: > > Well, by default step 3 fails if you have upstream changes. > > I'm not sure what you mean by "upstream changes". Do you mean changes > outside the Debian directory ?
Yes. This was discussed on debian-devel and it was considered to be a better default behaviour. Discussion starts at: http://lists.debian.org/20110529085303.ga17...@rivendell.home.ouaza.com > If so I wasn't aware of it. Perhaps I > didn't read the manpage clearly enough. I think that is also broken. > It seems to me that the most basic requirement of an archive source > format is that the four operations I describe above should work and > DTRT. Well doing the right things with "3.0 (quilt)" means (for most people) to keep the source package tree actually usable with quilt, so actually recording "non-quilt managed" changes in a new quilt patch. > Ie: > (i) dpkg-source -b should be able to run on any reasonable tree > (ii) dpkg-source -b should not modify the directory it is run in > (iii) dpkg-source -x should always produce the same tree as > was fed to dpkg-source -b > But as I understand you, `3.0 (quilt)' violates these and this > deliberate. > > If I have understood you, dgit won't work properly if you make the > "wrong" kind of change, so I need to either have this fixed, or (more > likely) to work around it (and bitch some more in the manpage). Does > "dpkg-source --commit" make any changes other than to quilt metadata ? > Perhaps dgit push should do that automatically. dpkg-source --commit adds a new patch in debian/patches/, it adds the corresponding quilt metadata, and it might also modify debian/source/include-binaries in case you have (modified/new) binary files that can't be represented in a quilt patch. I agree that it should be called automatically before trying to build the source package. At least for formats "2.0" and "3.0 (quilt)", it doesn't fail with "1.0" but does nothing except spitting out a small message “'dpkg-source --commit' is not supported by the source format '1.0'”. But you should be aware that it's an interactive command, it will ask for the patch name (thought this can be avoided by feeding it on the command line) and it will run sensible-editor to let the user edit the DEP-3 metadata on top of the generated patch. OTOH, if you use --auto-commit, you get back to the old behaviour and dpkg-source -b will work and create the new patch non-interactively. (aka dpkg-buildpackage --source-option=--auto-commit -S) > > You put "single-debian-patch" in debian/source/local-options (or …/options > > if you want to keep it in the generated source package). > > > > (=> with "local-options" this is another case of something that you can > > have in your tree and that you won't have in the unpack of the generated > > source package) > > It seems to me that it is the maintainer who determines the source > package format. Therefore putting this in local-options makes no > sense. On the contrary, the maintainer uses a VCS based workflow and generates a single patch on every upload. But then if someones does an NMU, you'd rather have dpkg-source generate a separate patch instead of updating the maintainer's monolothic patch. Putting it in local-options (in the git repository) achieves exactly that. > > Are those commits replacing all the files or are they actually a merge of > > changes from upload_n-1 to upload_n in the git repository? > > Each upload is represented as a new root commit whose tree contains > the files which are the result of "dpkg-source -x". This is then > merged into the existing head of the suite's branch in dgit-repos with > a pseudo-merge (ie, a merge which takes content only from one of the > parents). The dgit-repos suite branches are fast-forwarding. And the content is taken from the parent which represents the uploads? So basically you overwrite any other changes that might have been done since the last upload? Otherwise there's no point in that pseudo-merge if it doesn't grab the changes made by this upload. So basically the difference with git-buildpackage is: - the uploads are represented by pseudo-merges from root commits (whereas with git-import-dsc you get non-deterministic commits because they are made on top of the upstream branch with a varying history) - you have a centralized repository for all packages - you define some default branches that track the centralized repository - you track in the source package the commit from which it has been generated Are there any other important differences? It seems to me that the value is really in the first feature because it allows merges to stop at the first common upload available in the history and thus work even though the repositories might sensibly differ. The centralization is a nice bonus but the fact that it's required is somewhat problematic, I don't see the point in duplicating data in another git repository when all my packages are already using git (and often in collab-maint so all DD have write access). It would be nice if it could rely on the Vcs-Git fields available in the archive and then optionally work on those repositories instead of dgit.debian.net. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130824082503.gc5...@x230-buxy.home.ouaza.com
