Ian Jackson writes ("Re: Intent to commit craziness - source package unpacking"): > Guido Günther writes ("Re: Intent to commit craziness - source package > unpacking"): > > 'gbp pq import' does have 'debian/patches' since it just puts the > > patches that are in debian/patches on top of the unpatched source > > tree. In contrast to your solution it doesn't try to be able to > > roundtrip without changes for any given series on "gbp pq export". This > > is only true if the series was also created by "gbp pq" (or adheres to > > what git-format-patch does). > > Currently the output of dpkg-source --commit doesn't look much like > the output of git-format-patch. > > I have tried to make dgit produce patches (when it needs to produce > patches) that look like dpkg-source --commit. But maybe it should > produce patches using git-format-patch (or that look like > git-format-patch).
I have looked at the specs (including DEP-3) and the behaviour of the various tools a bit more. I have decided that when I should replace dgit's adhoc algorithm for generating a DEP-3 compliant commit message, with a call to git-format-patch. (The actual patch body has to come from dpkg-soure, because of the special handling of debian/, etc. This code path is used when a dgit user is pushing and needs to convert raw git commits into `3.0 (quilt)' patches.) And, after having half-written a DEP-3 importer (ie a thing that turns a DEP-3 patch message into a git commit), and investigating the behaviour of various tools, I have decided I should just use gbp pq. (This will replace the repeated use of dpkg-source --before-build as a described in my previous mail.) This will mean that dgit will grow a hard dependency on git-buildpackage. Because I'm a pernickety type of person I reviewed the dependencies of git-buildpackage. I have some qualms about the following dependencies: Recommends: pristine-tar (>= 0.5) pristine-tar has been declared unmaintainable by its original author and abandoned. IDK know what proportion of actual git trees that gbp users will encounter would break without pristine-tar. Perhaps this dependency can be demoted to Suggests, but I don't really know. Certainly dgit users do not need pristine-tar. But our dependency system does not allow us to honour only direct Recommends and not transitive ones. Recommends: cowbuilder <= jessie Recommends: cowbuilder | pbuilder | sbuild <= sid Many users of dgit will never want to build a package for upload. This is probably true of gbp users too. I'm not sure why it's valuable to have this as a Recommends dependency for gbp. I think more people now are using sbuild. I'm not sure that pulling in cowbuilder on systems where the user has not yet installed such a tool is right. Depends: devscripts devscripts is very full of commands with poor namespacing. It also has an enormous dependency chain. Unfortunately dgit has a dependency on devscripts too. Maybe we should work to take the pieces of devscripts that we really need and put them in something else, or something. Overall I don't think these are an impediment. But since I had done the review, I thought I'd share my thoughts. Regards, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. _______________________________________________ vcs-pkg-discuss mailing list firstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss