binary_package_name: null
trusted_certs: null
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61
Format: 1.8
Date: Sat, 30 Sep 2023 18:12:57 +0930
Source: gitpkg
Binary: gitpkg
Architecture: all
Version: 0.31
Distribution: sid
Urgency: medium
Maintainer: Ron Lee <ron@debian.org>
Changed-By: Ron Lee <ron@debian.org>
Description:
gitpkg - tools for maintaining Debian packages with git
Closes: 734360
Changes:
gitpkg (0.31) unstable; urgency=medium
.
* Support exporting submodules as part of the superproject package.
Closes: #734360
It's been a while since we had any follow up or feedback on the discussion
in that bug, so it's not clear that submodules remain a wide use case, but
I've now got one upstream repo really using them (though it probably would
be better organised differently too) so I at least have something concrete
to base the gitpkg behaviour on rather than just a strawman speculation on
my part about how a repo with submodules might be arranged and operated.
.
The originally proposed patch had quite a few limitations, it only worked
on exports of the debian-treeish, not for a real orig-branch, and it used
git submodule foreach, which only works on the current checked out state
of the working dir and so breaks one of gitpkg's fundamental modes of
operation where any revision can be exported at any time, regardless of
the current state of the repo working dir. This implementation is quite a
bit more involved, but it should handle most or all cases, including where
submodules have been moved or later deleted, provided the local repo has
been fully initialised and all submodules which may need to be exported
have been cloned into the superproject and its full history is intact.
.
It will not simply export submodules by default, though it if finds them
present in a repo that has not been configured to export (or ignore) them
then it will prompt asking what immediate action should be taken and
suggest configuration to avoid be prompted again subsequently. This way
existing repos that have been silently ignoring submodules thus far will
not silently do something surprisingly different with this gitpkg release.
.
* Sanity check and/or warn if gitpkg is invoked from a submodule dir, since
that probably won't do what a lot of people might naively assume, but it
might still be something that some pathological repo actually has a use
case for. We probably shouldn't encourage it though.
.
* Bump to debhelper compat 12. That give us no-patch builds back to buster
which is still a supported release. We don't actually need anything from
newer dh in this package, so this is just to stay ahead of the arbitrary
'deprecated version' warnings rather than to actually fix anything.
Checksums-Sha1:
fec313f4b1c2cf2779b092b5bf3d8374fd2fab82 50956 gitpkg_0.31_all.deb
9f4d0e4fd92bd07178f58d86bbbf9530b49a0096 4542 gitpkg_0.31_arm64.buildinfo
Checksums-Sha256:
12ff61abf06acc038ca51aa49a3a695902446abf9fce066a79e76ecf47bfb3e3 50956 gitpkg_0.31_all.deb
709ea3041d2dd8c5bb970972df03b8a0f217727067168a3286d51c8d74bf31c2 4542 gitpkg_0.31_arm64.buildinfo
Files:
5fa8fc81d54cf3c3bc08bc433ee56d36 50956 vcs optional gitpkg_0.31_all.deb
697c9d4ec7eaa5573a72ce92f3d02c27 4542 vcs optional gitpkg_0.31_arm64.buildinfo
Relation | Direction | Type | Name | |
---|---|---|---|---|
relates-to | Package upload | gitpkg_0.31 |
|