Re: using git-dpm or plain git-buildpackage in PAPT and DPMT
On Aug 10, 2016, at 11:53 AM, Nikolaus Rath wrote:
>I think the only way to make this less painful is to get rid of the idea
>of managing patches in a VCS and use something like gitpkg. This has the
>drawback source package is now *generated* from the Git repository
>(i.e., you can't do git clone + debuild), but it makes maintaining the
>Git repository much less painful. Judging from all the attempts I've
>seen so far, trying to put patches (i.e., the output of a VCS) under
>version-control is just a doomed endeavor.
>
>I don't believe that switching from git-dpm to git-buildpackage is going
>to make things easier, it'll just be trading one set of problems for
>another.
Two thoughts:
* We probably need to do some actual experimentation on actual packages, so
we should plan for allowing that on a limited basis, with the caveat that
once a new workflow is chosen, we'll make all team packages consistent
again.
* With git-dpm we *had* to enforce the tool choice because git-dpm's artifacts
had to be preserved. If we ditch git-dpm, is that still the case? IOW, if
you choose to use gbp-pq, am I forced to do so when I modify the same repo?
Or if you choose to use PoQ (plain 'ol quilt), will that affect how others
can co-maintain the package in git?
We only need to mandate workflows and conventions where the effects and
artifacts are visible after a package is updated. Think of it like the choice
of editor - no one cares whether you use vim, emacs, gedit, or whatever to
modify the files, because its effects are only local to you (for the most
part).
Cheers,
-Barry
Reply to: