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?
>
> >
> >> >> 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
