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