Otto Kekäläinen <[email protected]> writes: > Hi! > > On Thu, 8 Jan 2026 at 08:15, Ian Jackson > <[email protected]> wrote: >> Simon Josefsson writes ("Re: Include git commit id and git tree id in >> *.changes files when uploading?"): >> > 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. 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). 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. /Simon > If a package is using git-buildpackage in the first place, the best > and really only sensible command to import new upstream versions is > `gbp import-orig --uscan` as Simon is already doing, and without any > additional parameters. > > This is important for two reasons: > > 1) Debian uses uscan and upstreams needs to be fetchable with debian/watch > info > > The whole Debian infrastructure (currently) expects all non-native > packages to have a debian/watch file, and that uscan will download the > upstream source package accordingly. Tools like vcswatch and the new > debaudit run uscan to fetch new and old versions. The package > maintainer should also be using this and not bypassing getting new > upstream versions with some other manual way. With this also anyone > auditing a potential backdoor can reproduce the import and (directly) > see it came from upstream and not from the maintainer in Debian. > > 2) Git-buildpackage settings should be in debian/gbp.conf for consistency > > While I suggest everyone to do upstream imports using `gbp import-orig > --uscan`, it does not mean all packages need to have the same settings > or git layout and so forth. I just consider it a major source of > problems if each maintainer runs the command and passes their own > extra parameters to it, as whoever later works on the package has no > way of knowing what those extra parameters were. By always using the > same generic command to do the import AND by having the settings > specific for that package in debian/gbp.conf we can ensure that > imports are consistent (and also anyone auditing what happened can > reproduce the import). > > Why does `gbp import-ref` exist then? That command is used when the > upstream import has already been done once into the git repository and > you want to import the same version to another branch. For example > when there is a new MariaDB version I run in branch `debian/latest` > the command `gbp import-orig --uscan` and eventually upload to > unstable. Later when I backport to Trixie I run in the branch > `debian/13-trixie` the command `gbp import-ref > --upstream-version=11.8.5` and git-buildpackage will automatically use > the upstream sources and tarball already in the git repository. > > Does this seem complicated? Yes, there are a lot of moving parts and > most Debian maintainers who want to focus on just packaging and not > learn all possible workflows and git layouts surely feel overwhelmed, > and we need to simplify this going forward. > > But for now most maintainers (meaning the subset who use > git-buildpackage) will get things correct by asking for each new > package these 3 questions: > > 1. Does upstream release tarballs? If so, enforce pristine-tar = True. > 2. Does upstream sign the tarballs? If so, configure explicit > signature checking with upstream-signatures = on. > 3. Does upstream have a Git repository, and does it have release Git > tags? If so, configure the release Git tag format, e.g. > upstream-vcs-tag = %(version%~%.)s. > > The above is a quote from > https://optimizedbyotto.com/post/debian-packaging-from-git/ for those > who want to read a longer explanation with "screenshots" and diagrams. > > The above post is using the Entr package in Debian as a real example, > and as you can see on the new debaudit pages it passes all green: > > https://debaudit.debian.net/orig-check/result/262f24ff0aa2ef9da6d40118294c404074c93753998db692b852b978dddf6a98 > https://debaudit.debian.net/git2dsc/result/262f24ff0aa2ef9da6d40118294c404074c93753998db692b852b978dddf6a98 > > > Simon: In your Go packages the vast majority should have > `upstream-vcs-tag = %v(version%~%.)s` (note the 'v' which is very > common for Go upstreams) and you should continue to always run `gbp > import-orig --uscan` as you do. The dh-make-golang will have this in > new gbp.conf files as soon as the PR that updates the template gets > merged. > > We should not stop using uscan. Maybe in the future if there are > better end-to-end workflows that everyone is happy with, but > prematurely abandoning relevant parts of the traditional workflow will > create a hard to manage mess, and potentially even large gaps in > software provenance and auditability. > > Hope this helps and clarifies things, > > Otto > >
signature.asc
Description: PGP signature
