❦ 4 janvier 2017 09:47 -0800, Nikolaus Rath <Nikolaus@rath.org> : >>>>> It's surprisingly awkward, and, at least for me, it turns out that >>>>> externalizing my rebased branch as a patch series solves many of >>>>> problems surprisingly well. All the other solutions I can think of >>>>> require one or more things I don't really want to do: rebase the >>>>> debian/master branch, not be able to run dpkg-buildpackage from the >>>>> debian/master branch easily, or require that dpkg-buildpackage do >>>>> more mucking about with source control than I want it to. >>>> >>>>I believe the git-dpm approach would give you everything you want. The >>>>explanation on http://git-dpm.alioth.debian.org/ is pretty good. >>>> >>>>I personally think that technically git-dpm's approach is the best - >>>>but >>>>unfortunately the program itself is effectively unmaintained and >>>>apparently/consequently not used by many people. >>> >>> The Debian Python Modules Team (DPMT) has about 1,000 packages with >>> git-dpm repositories. While it took a bit of getting used to and >>> there have been a few problems, overall I think it's worked very well. >>> It's biggest problem is the lack of a maintainer. >> >> There have been a lot of complaints about it. For me, it is a pain to >> use. Its integration with gbp is poor, > > Well, I think that is because it is mostly an *alternative* to > gbp. Other than gbp dch (which I think should work fine), what features > of gbp would you like to use with git-dpm? gbp import-orig --uscan (the whole import with git-dpm is flawed, there are too many ways to fail, like a patch that cannot be rebased and the pristine-tar branch is not updated, like the previous upstream was not tagged because not released [and git-dpm only tags upstream when master is tagged] and it fails in the middle of the process, gbp rollbacks when there is a problem). -- Few things are harder to put up with than the annoyance of a good example. -- "Mark Twain, Pudd'nhead Wilson's Calendar"
Description: PGP signature