Hi! On Mon, 2016-09-26 at 15:37:19 +0100, Ian Jackson wrote: > tl;dr: > > * dpkg developers, please tell me whether I am making assumptions > that are likely to become false. Particularly, on the behaviour of > successive runs of dpkg-source --before-build with successively > longer series files.
For format «3.0 (quilt)», that seems fine, to the point I'm fine even documenting this, which I can probably do for 1.18.11. For other formats, such as «2.0», I don't think that's true, but I assume you don't care about that one anyway. But just mentioning because this behavior is probably format-specific. For «2.0» I think it could be fixed, and should not be too hard (not sure if it's worth it though). > dpkg-source does not currently provide interfaces that look like they > are intended for what I want to do. And dgit wants to work with old > versions of dpkg, so I don't want to block on getting such interfaces > added (even supposing that a sane interface could be designed, which > is doubtful). Even then I'm still interested in a decription of what you'd need ideally, to take into account when having a pass at cleaning up that part of the interface. I think you could be interested in a cleaner Dpkg::Source::* hierarchy, for the mid/long-term? Perhaps we could start a wiki page listing such items. > So I intend to do as follows. (Please hold your nose.) > > * dgit will untar each input tarball (other than the Debian tarball). > > This will be done by scanning the .dsc for things whose names look > like (compressed) tarballs, and using the interfaces provided by > Dpkg::Compression to get at the tarball. Hmm, Dpkg::Source::Archive is currently private, but I might have a look at making it public if that would be helpful here. > * As currently, dgit will take steps so that none of the git trees > discussed above contain a .pc directory. As long as the directory does not disappear from the working tree, that should work. > This has the following properties: > * dgit now depends on dpkg-source --before-build idempotently applying > patches as they successively appear on debian/patches/series. Again, that seems fine. Thanks, Guillem
