Hi, > >> > Right. I use 'gbp import-orig --uscan' to import new upstreams. > >> > >> You should perhaps consider switching to gbp import-ref. Thanks to > >> Gioele Barabucci for the tip. AIUI golang packages are primarily in > >> git almost by definition. > > > > I think Gioele wanted to point out that git-buildpackage has this > > feature. It should not be construed as a suggestion to import new > > upstream versions with it. Let me explain. > > Thanks for explaining! > > Could you clarify if 'gbp import-orig' will do anything substantially > different than > > git checkout upstream > git fetch up > git checkout -B upstream up/v1.2.3 > git checkout debian/latest > git merge upstream > > in a "friendly low-complexity upstream" case when 1) debian/gbp.conf has > upstream-vcs-tag and 2) debian/watch points to upstream git? Assume we > don't have to care about debian/copyright Files-Excluded and other > complexity that doesn't hold for >50% of packages.
I recommend as the best way to see what is happening, is to do a mock import on the Debian packaging repository as suggested in https://optimizedbyotto.com/post/debian-packaging-from-git/#import-new-upstream-versions-in-the-future -> https://optimizedbyotto.com/post/debian-source-package-git/#try-it-yourself-example-repository-galera-4-demo cd $(mktemp -d) gbp clone --add-upstream-vcs https://salsa.debian.org/otto/galera-4-demo.git cd galera-4-demo/ gitk --all & (gitk here is important so you see the state of the git repo and all the branches before the import) gbp import-orig --uscan --verbose (--verbose will show all the git commands that ran) After the import hit F5 in the gitk window to see the state after the import, and to easily inspect all branches, commits and read tag contents. A poor ASCII representation after import is: * 2b853aba Update upstream source from tag 'upstream/26.4.24' 58 seconds ago (HEAD -> debian/latest) |\ | * 4108aafa New upstream version 26.4.24 64 seconds ago (tag: upstream/26.4.24, upstream/latest) | |\ | | * c71ef30a MDEV-35964 make sure to process CCs which are contianed in SST. 4 months ago (tag: release_26.4.24, upstreamvcs/4.x) | | * e928c38c Bump Galera version to 26.4.24 4 months ago > The way I understand Ian/Sean (and I have to admit that often do a poor > job of that) is that they advocate for Debian's source code contain an > upstream git branch that matches upstream's git commit for a release. > This seems reasonable to me (but has corner cases that makes this a > non-generic solution). I actually advocate for Debian's source code contain an upstream git branch that matches upstream's git commit for a release. Also DEP-14 advocates for an upstream import branch to exists, although it does not say how to do the import. If you do the demo import above you can do things like run `git blame` on any file to see the true origin and all the git commit ids are the real upstream ids: ± git blame GALERA_VERSION 5d0299939 (Teemu Ollakka 2020-11-08 13:42:39 +0200 1) GALERA_VERSION_WSREP_API=26 5d0299939 (Teemu Ollakka 2020-11-08 13:42:39 +0200 2) GALERA_VERSION_MAJOR=4 e928c38cf (Jan Lindström 2025-09-09 06:58:35 +0300 3) GALERA_VERSION_MINOR=24 a0a3952b7 (Teemu Ollakka 2020-12-28 17:09:55 +0200 4) GALERA_VERSION_EXTRA= > And you seem to advocate for using 'gbp import-orig --uscan'. This also > seems reasonable to me. > > I'm trying to find a middle ground where these two meet and lead to the > exact same end result, and it appears to happen if 1) and 2) hold, or I > may be missing something. Yes, this is overly complicated, but this is how things are now. We should spec a Debian source package format 3.1 or 4.0 in the future with mandatory upstream git url and a file that records the exact sha256 checksum of upstream imports and so forth, but that is a discussion for another day. Personally I am coping with the current situation by using git-buildpackage in a way that leverages as much as possible of git and things I expect to be able to do in modern software development (e.g. CI and code reviews on a forge) without breaking backwards compatibility with traditional source packages or any existing Debian infra systems.
