On Wed, Jan 04, 2017 at 10:28:10PM +0100, Sebastian Andrzej Siewior wrote: > On 2017-01-03 16:58:21 [+0000], Ian Jackson wrote: > > Looked at another way, it is trying to be a version control system, > > layered on top of the Debian archive. But it is only about a quarter > > of a VCS. There are no formal interfaces to do proper VCS operations. > > If there is a formal interface, it is quilt(1) (which is itself very > > poor. NB that is not quilt's fault: quilt inevitably has a hard job > > because can't make enough assumptions). > > there quilt push, pop and header which seems enough. quilt is not a hard dependency of dpkg-dev, but the abstraction is quite leaky without it: if you try to build a 3.0 (quilt) package without having quilt, dpkg-buildpackage will apply the patches fine, but if something breaks and you have a half-built tree, things are pretty messy and I often rely on rm -rf .pc and git reset (when I have the advantage of working in a git repository) to get back to a buildable source. I'd much prefer if it the state of a build tree after 'dpkg-buildpackage' could be wound back without relying on external (or non-depended) tools, it would help me feel that the tool was well rounded and internally consistent. -- Jonathan Dowland Please do not CC me, I am subscribed to the list.
Attachment:
signature.asc
Description: Digital signature