Does upstream want to have Debian packaging?

[ottok]

Hi,

I've packaged this for Debian and got it included in Debian officially, and by extension also Ubuntu:

https://tracker.debian.org/pkg/golang-github-pingcap-failpoint

https://launchpad.net/ubuntu/+source/golang-github-pingcap-failpoint

Are you here at upstream interested in having this debian/ subdirectory and the packaging? If yes, I can file a PR to submit it.

You can use it to generate .deb packages directly at upstream, or for example include the .deb generation it in the CI to be able to detect if any changes in upstream failpoint are incompatible with Debian and breaks the package.

CC: @dveeden

[dveeden]

So after adding debian/ to upstream:

• We should add a CI job to build the packages (should be easy). Do we need to build for all Debian/Ubuntu versions?
• Then we should try to install the generated package to ensure it still works
• Maybe check Lintian output?
• Best would be to actually test the package by running a few commands after install.

[ottok]

So after adding debian/ to upstream:

• We should add a CI job to build the packages (should be easy). Do we need to build for all Debian/Ubuntu versions?

Building for Debian unstable would suffice. If latest version of this package is compatible with latest in Debian unstable, what flows to the older releases is likely going to be coupled together and continue to work as previously.

• Then we should try to install the generated package to ensure it still works

Alternatively build TiUP in Debian unstable and use the failpoint version from the git commit to be tested as a build dependency and theck that TiUP build does not fail?

• Maybe check Lintian output?

Perhaps. There is also autopkgtest, but it only runs the same Go tests that are automatically run as part of the build already.

• Best would be to actually test the package by running a few commands after install.

That is ideal of course. This is mainly a decision of how much effort makes sense to put on this. The build alone is already a win and will detect if libraries or Go tests fail and have become incompatible.

[ottok]

After pondering about this, I decided I should submit native Debian packaging for pingcap/kvproto#1416 first, as it has more complex dependencies (on protobuffer and C/C++ libraries) and thus is larger interface to detect version incompatibilities and is a better place to experiment with potential CI changes on how to best be tracking Debian unstable and detect future incompatibilities early.

Related to Debian packaging, note that this failpoint module is one of the few PingCAP modules that does not have any release tags. Hence the version in Debian is simply the git commit b51a646 (plus one patch) because TiUP v1.6.3 depended on it. As of writing, TiUP master branch still depends on this commit b51a646 (github.com/pingcap/failpoint v0.0.0-20240528011301-b51a646c7c86) from 2024.

[dveeden]

I think the kvproto is very important to TiKV and TiDB, but less so for TiUP, so a somewhat older version is probably not a real problem. However, might still make sense to update it and not let it fall behind.