Hi, > Third, we extend DEP-14 to distinguish between > pristine-maybe-not-DFSG-clean Git branches and upstream/ branches on top > of which the debian/ branches are based. > > * upstream/latest-dfsg-unclean will be exactly the upstream master branch.
Actually DEP-14 (https://dep-team.pages.debian.net/deps/dep14/) does not require that you have real git upstream history in the Debian packaging repo, nor that you have a 'upstreamvcs' remote. But if you have it, the upstream branches will use the upstream names, along with real upstream git commit ids and tags and all of them being consistent and original, with upstream signatures intact etc. So there is no need for 'upstream/latest-dfsg-unclean', it is simply called 'main' or whatever name upstream uses. > * upstream/latest is an offspring of upstream/latest-dfsg-unclean that > contains an extra commit where Files-Excluded files are git-rm'd [1]. In DEP-14 the 'upstream/latest' refers to the *import* of the upstream (either from tarball, directly a git object, or both), not the real upstream branch (e.g. 'main'). So in DEP-14 already the 'upstream/latest' is an offspring of the upstream 'main' branch (or actually the upstream release tag, as we don't usually import just any branch HEAD commit but specifically the release commits). > * debian/latest will be based off upstream/latest. Yes, this is how DEP-14 already defines it and how git-buildpackage and other tools do it. > Once this is in place, orig tarballs generated by gbp export-orig and > tag2upload will automatically be DFSG-clean. > > gbp could be modified to support this new layout and to do all the > necessary adjustments (like automatically adding +dfsg to the debian > version). This is already there. I don't think any changes to DEP-14 or gbp are needed. I have been using this scheme for all my packaging for a couple years now. If you have gbp.conf:upstream-vcs-tag the 'gbp import-orig --uscan' will automatically pull upstream git objects and they will be in your packaging repo using real upstream commit ids and original real upstream tag names, and in most cases the real upstream branch using the real upstream branch name. If you have copyright:Files-Exclude the 'upstream/latest' will have stuff removed, and git-buildpackage will automatically append +ds to the version. Perhaps this is easiest to grasp by looking at a real example: Godot - Files are excluded in https://salsa.debian.org/games-team/godot/-/blob/debian/latest/debian/copyright - Upstream repository is defined in https://salsa.debian.org/games-team/godot/-/blob/debian/latest/debian/upstream/metadata - 'upstream-vcs-tag = %(version)s-stable' is defined in https://salsa.debian.org/games-team/godot/-/blob/debian/latest/debian/gbp.conf - tarball source is defined in https://salsa.debian.org/games-team/godot/-/blob/debian/latest/debian/watch When running 'gbp import-orig --uscan' it did: 1. fetch tags from upstreamvcs remote 2. see tag 4.4.1-stable: https://salsa.debian.org/games-team/godot/-/commit/49a5bc7b616bd04689a2c89e89bda41f50241464 3. merge tag 4.4.1-stable on 'upstream/latest' using tarball contents and filtering applied and tag it as 'upstream/4.4.1+ds': https://salsa.debian.org/games-team/godot/-/commit/f749a993d44afaf6afbb81dde3f05f8afb062db9 4. merge 'upstream/4.4.1+ds' (that is on the 'upstream/latest' branch) on 'debian/latest': https://salsa.debian.org/games-team/godot/-/commit/8c34262462a8be5761f1a981de25cc138cba5612 ± git log --graph --oneline * 3cc006b6bc2 (HEAD -> debian/latest, tag: debian/4.4.1+ds-1, origin/debian/latest) Release 4.4.1+ds-1 to unstable (... packaging commits ...) * 8c34262462a Update upstream source from tag 'upstream/4.4.1+ds' |\ | * f749a993d44 (tag: upstream/4.4.1+ds, origin/upstream/latest, upstream/latest) New upstream version 4.4.1+ds | |\ | | * 49a5bc7b616 (tag: 4.4.1-stable) Bump version to 4.4.1-stable You can upload this using 'git-buildpackage -S' + dput, or 'git debpush' or 'dgit push'. All of them will generate the godot_4.4.1+ds-1.orig.tar.gz from branch 'upstream/latest' (or actually the specific commit tagged 'upstream/4.4.1+ds'). My previous email had Galera as an example. It does not have any copyright:Files-Exclude, so it does not generate any +ds versions or tarballs, but the commands to operate git-buildpackage are exactly the same as for Godot. All the filtering and +ds is automatic as per config files, no commands change. The Galera example does however have this documentation with the full end-to-end workflow commands: https://salsa.debian.org/mariadb-team/galera-4/-/blob/debian/latest/debian/README.source.md?ref_type=heads#download-upstream-release-tarball-and-import-using-both-git-tag-and-tarball That might help grasp how all this fits together and how I am using git-buildpackage to have as much git magic and automation as possible, and host it on Salsa in a form where anyone can see what development is done and easily fork and open MRs.
