changes_fields:
Architecture: all
Binary: gitpkg
Changed-By: Ron Lee <ron@debian.org>
Changes: |2-
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:
- name: gitpkg_0.31_all.deb
sha1: fec313f4b1c2cf2779b092b5bf3d8374fd2fab82
size: '50956'
- name: gitpkg_0.31_arm64.buildinfo
sha1: 9f4d0e4fd92bd07178f58d86bbbf9530b49a0096
size: '4542'
Checksums-Sha256:
- name: gitpkg_0.31_all.deb
sha256: 12ff61abf06acc038ca51aa49a3a695902446abf9fce066a79e76ecf47bfb3e3
size: '50956'
- name: gitpkg_0.31_arm64.buildinfo
sha256: 709ea3041d2dd8c5bb970972df03b8a0f217727067168a3286d51c8d74bf31c2
size: '4542'
Closes: '734360'
Date: Sat, 30 Sep 2023 18:12:57 +0930
Description: |2-
gitpkg - tools for maintaining Debian packages with git
Distribution: sid
Files:
- md5sum: 5fa8fc81d54cf3c3bc08bc433ee56d36
name: gitpkg_0.31_all.deb
priority: optional
section: vcs
size: '50956'
- md5sum: 697c9d4ec7eaa5573a72ce92f3d02c27
name: gitpkg_0.31_arm64.buildinfo
priority: optional
section: vcs
size: '4542'
Format: '1.8'
Maintainer: Ron Lee <ron@debian.org>
Source: gitpkg
Urgency: medium
Version: '0.31'
type: dpkg