Hi On Sat, Feb 29, 2020 at 09:43:55AM -0700, Sean Whitton wrote: > Hello Matt, > > On Sat 25 Jan 2020 at 04:06PM -08, Matt Taggart wrote: > > > I am following the the "When upstream tags releases in git" section of > > dgit-maint-merge(7) and when I get to the "Now go ahead and > > Debianise..." section I'd like to be able to run debmake, but it's > > expecting the source dir to have a particular name and the orig tarball > > to exist. > > Ah, okay. It seems that the problem with debmake you identify here is > not specific to dgit-maint-merge(7), as most any git-based workflow will > not have the source dir include the version number, and many of them > won't have the orig.tar exist yet. > > >> s/debhelper/debmake/ right? > > > > Yes, sorry. > >>> 1) don't create debian/patches/ > >>> > >>> 2) don't create debian/source/local-options > >>> > >>> 3) I'm not sure if watch is needed > >>> > >>> 4) create debian/source/options containing: > >>> single-debian-patch > >>> auto-commit > >>> > >>> 5) create debian/source/patch-header with a description of how to get > >>> changes to the upstream source. I guess this should be a template that > >>> fills in package name and git repo? > >>> > >>> For #3 and #4 see the dgit-maint-merge(7) manpage for examples and > >>> explanation. > >> > >> I think that debmake might not be the right place for (2), (4) and (5). > >> Instead, I think a 'maintmerge' script in the dgit package should do > >> that setup, so that non-debmake users can take advantage. See #852226. > > > > debmake is already creating a template for (2). > > I like the idea of putting these steps in a dgit script though and > > having the dgit-maint-merge(7) manpage explain how to use it. Then maybe > > debmake could add a basic mode to handle the other remaining things. > > I agree.
Please propose patch :-) I want debmake to work smoothly with dgit work flow. I really wish debmake to become really thin glue code. Another action plan is replace license check code woth external utility Osamu
