Otto Kekäläinen <[email protected]> writes: > 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.
Right, but that project doesn't use debian/watch mode=git? So I'm not sure this is comparable. Here is another example. jas@frallan:~/dpkg$ git clone [email protected]:go-team/packages/golang-github-protocolbuffers-txtpbfmt.git jas@frallan:~/dpkg$ cd golang-github-protocolbuffers-txtpbfmt jas@frallan:~/dpkg/golang-github-protocolbuffers-txtpbfmt$ cat debian/watch version=4 opts="mode=git, pgpmode=none" \ https://github.com/protocolbuffers/txtpbfmt.git \ HEAD debian # Use the following when upstream starts to tag releases: # #version=4 #opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%,\ # uversionmangle=s/(\d)[_\.\-\+]?(RC|rc|pre|dev|beta|alpha)[.]?(\d*)$/$1~$2$3/" \ # https://github.com/protocolbuffers/txtpbfmt/tags .*/v?(\d\S*)\.tar\.gz debian jas@frallan:~/dpkg/golang-github-protocolbuffers-txtpbfmt$ cat debian/gbp.conf [DEFAULT] debian-branch = debian/sid dist = DEP14 jas@frallan:~/dpkg/golang-github-protocolbuffers-txtpbfmt$ git remote add up https://github.com/protocolbuffers/txtpbfmt.git jas@frallan:~/dpkg/golang-github-protocolbuffers-txtpbfmt$ git fetch up jas@frallan:~/dpkg/golang-github-protocolbuffers-txtpbfmt$ gbp import-orig --uscan --upstream-vcs-tag=fcb97cc However this still creates a merge commit in the upstream branch: commit 57d77483f79cb82e667e3d9a1fc45c5cc470d3cc (tag: upstream/0.0_git20251124.fcb97cc, upstream) Merge: fba763a fcb97cc Author: Simon Josefsson <[email protected]> Date: Tue Jan 13 08:29:48 2026 +0100 New upstream version 0.0~git20251124.fcb97cc Sigh, so it seems I was wrong, and now I know of no way to teach 'gbp import-orig' to behave like Ian/Sean would prefer it to do. To be honest, I find these GBP synthesized merge commits just noice. What value do this add? Why can't the 'upstream' branch be the upstream branch without any GBP modifications? Couldn't GBP support that? For some packages, I've created such a solution manually, and GBP seems to cope well with that once it is in place. Perhaps 'gbp import-ref' is the answer here. > I actually advocate for Debian's source code contain an upstream git > branch that matches upstream's git commit for a release. Do you mean "matches" as in the same git commit identifier, or just bit-by-bit identical content but can have the GBP merge commit? >> 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. Indeed. I think we all seem to share the same concerns, and everyone try to establish some order to the mess we are in, and we all seem to create slightly different approaches when establishing order, and then try to argue that their approach is the most reasonable one. Maybe the argument should be what to do about the mess rather than which approach to use to deal with the mess. But that is a much harder problem, so we are probably stuck debating which approach to use... 50.000+ packages used to be a lot to maintain in a single version control repository. By todays standard, it isn't. I suspect if you take all of Deabin's debian/ source directories and put them in a single git repository, it would not be that much larger than say Guix, Homebrew, NixOS, Fedora or some other more centralized packaging system. /Simon
signature.asc
Description: PGP signature
