Ship a git .bundle in .dsc and .deb

[Agathe Porte <gagath@debian.org>]

Hello everyone,

I have recently packaged qmk¹ into debian² (see rationale³).

However the tool still needs to git clone the qmk_firmware repository⁴
at runtime before being able to do any work. This is what the
autopkgtest currently does⁵, with the needs-internet restiction⁶.

¹ https://github.com/qmk/qmk_cli/
² https://tracker.debian.org/pkg/qmk
³ https://people.debian.org/~gagath/posts/2024/08/04/qmk-available-in-unstable/
⁴ https://github.com/qmk/qmk_firmware/
⁵ https://salsa.debian.org/python-team/packages/qmk/-/blob/debian/latest/debian/tests/clone-and-build.sh?ref_type=heads
⁶ https://salsa.debian.org/python-team/packages/qmk/-/blob/debian/latest/debian/tests/control?ref_type=heads

I was thinking of packaging qmk_firware into Debian in the form of a
native (3.0) package that would contain a git bundle of the upstream git
repository, and ship in for example in
/usr/src/qmk_firmware/qmk_firmware.bundle

Pros:

- Offline autopkgtest
- Faster autopkgtest?
  (remote counting objects takes time, git clone is >1 minute IIRC)
- Users can add the bundle as a remote or git clone it to get started

Cons:

- Big binary blob in source package?
- Impossible to pass ftp-master even if script to recreate bundle is
  provided?

Note that the qmk tool does require a git repository to work, so I did
not consider shipping only the code.

Or maybe I could tar the upstream .git folder and store everything else
as plain files? But still a binary blob in source package. And
extracting the tar into a .git in the filesystem in /usr/share/ may
raise a lot of Lintian warnings?

Cheers,

Agathe.