[+cc raphael (listed as DEP-14 driver)] Sorry for the long delay.
On Wed, Nov 8, 2017 at 9:00 AM, Guido Günther <a...@sigxcpu.org> wrote: > Hi, > On Tue, Nov 07, 2017 at 10:07:54PM +0100, Michael Stapelberg wrote: > > Thanks for your reply. Answers inline: > > > > On Mon, Nov 6, 2017 at 8:59 AM, Guido Günther <a...@sigxcpu.org> wrote: > > > Hi, > > > On Tue, Oct 31, 2017 at 05:24:05PM +0100, Michael Stapelberg wrote: > > >> Hi Guido, > > >> > > >> The pkg-go team is currently discussing changes to its workflow, and > > >> we’d be interested in resolving this feature request. > > > > > > Can you provide a pointer to the discussion? > > > > Have a look at https://lists.alioth.debian.org/pipermail/pkg-go- > maintainers/Week-of-Mon-20171016/015809.html > > > > > > > >> > > >> Guido Günther <a...@sigxcpu.org> writes: > > >> > I would rather do this with a dfsg-clean branch. You delete once and > > >> > then use git tools from there on. > > >> > > >> Searching for how dfsg-clean branches should be named, I found > > >> https://honk.sigxcpu.org/projects/git-buildpackage/ > manual-html/gbp.branch.naming.html, > > >> which recommends “dfsg/latest”. > > >> > > >> However, my reading of section “About repacked upstream sources” of > > >> http://dep.debian.net/deps/dep14/ directly contradicts the above > advice: > > >> DEP14 says upstream/* should contain the repackaged files. > > >> > > >> How do we reconcile this apparent contradiction? > > > > > > Since gbp makes no assumptions on this I'm happy to update the docs. > How > > > would we call the non-filtered branch then "nondfsg/latest"? When we > > > base our packaging on upstream git we'll likely use upstream's branch > > > name but in case of tarballs we should provide a good recommendation. > > > > Just to make sure we’re talking about the same thing: the branch > > you’re asking for naming recommendations is currently called > > “upstream”, yes? > > Yes, I'm talking about the branch or rather namespace that has the > pristine, unfiltered upstream sources. We probably don't need such a > name if upstream uses git but in the case of tarballs when one wants to > keep the unfiltered source. > > > If yes, then I don’t particularly like the name “nondfsg/latest”, as > > it is a double-negative, but describes a very common case. Why not > > keep calling it “upstream”, or “upstream/latest” if symmetry is > > desired? > > Isn't that what we're using for the filtered sources. The longer I think > about it I think that > > https://honk.sigxcpu.org/projects/git-buildpackage/ > manual-html/gbp.branch.naming.html > > fits better than DEP14. Maybe we should modify DEP14 to say that > upstream/ keeps the unfiltered source and dfsgclean/ the filtered one? > Raphael, any thoughts? > > > > > > > > >> >> It would be great if gbp could produce the 1.2.3+dfsg tag itself by > > >> >> reading debian/copyright and excluding the Files-Excluded: files. > > >> > > > >> > If somebody comes up with a clean patch I'm happy to merge that. > > >> > > >> Which part of gbp specifically should be patched here? AFAICT, there > is > > >> no command which pulls a new version from upstream yet. Should one be > > >> added? What should it be called? > > > > > > My first reaction was to teach gbp import-orig to have a > > > > > > gbp import-orig "git-ref" > > > > > > mode that would do the right thing but I now think having > > > > > > gbp update "git-ref" > > > > > > that > > > > > > - does the excluding and tagging if necessary > > > - merges to the debian branch > > > > > > is better. We need to make sure that gbp import-orig's filtering (using > > > the --filter command line or filter= gbp.conf option) stays in sync > with > > > what we do so we don't have on tool using --filter= and the other one > > > parsing debian/changelog. > > > > You’re saying gbp import-orig and gbp update should both support the > > same filter option, in additon to d/copyright, yes? > > Yes. > > > > > > > > > If somebody comes up with a better name than "update" that's all fine. > > > > “update” is a rather generic term. Given that the underlying git > > operation is “git pull”, how about “gbp pull-upstream”? > > See > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812721#25 > > alternatively "gbp import-ref". pull-upstream is wired since we want the > upstream namespace to contain the already filtered sources. > Cheers, > -- Guido > -- Best regards, Michael
