[KonradBreitsprecherBkd]

Adds relocatable tarballs for Ubuntu 20.04, CentOS 7 and AlmaLinux 8 with separate debug tarballs. It also introduces release/packages.json as the single definition of the Linux packages and rewrites the packaging workflow around it. Part 2 of 3; it is based on #62 (containers) and has to be merged after it.

release/packages.json

Every target names its build image, format, platform, a plain test image, release and its asset globs.

Target	Released assets
ubuntu-20.04-x86_64-deb	libsilkit5, libsilkit-dev, silkit-utils debs, libsilkit5-dbgsym ddeb, .buildinfo
ubuntu-20.04-x86_64-tgz	libsilkit-<ver>.ubuntu2004.x86_64.tar.gz + .debug.tar.gz
centos-7-x86_64-tgz	libsilkit-<ver>.el7.x86_64.tar.gz + .debug.tar.gz
alma-8-x86_64-tgz	libsilkit-<ver>.el8.x86_64.tar.gz + .debug.tar.gz
ubuntu-22.04-aarch64-deb, alma-9-x86_64-rpm	built and tested, release: false

sil-kit-delivery publishes the assets of the released targets to the releases of vectorgrp/sil-kit and this repository (sil-kit-delivery#161, internal). The make-release job is removed. The deb is then built once instead of twice; today the 5.0.8 deb has a different sha256 here than on vectorgrp/sil-kit.

Tarballs (scripts/silkit_tgz.py, pkgformat: tgz)

Built with cmake/ctest like the deb: RelWithDebInfo, SILKIT_BUILD_LINUX_PACKAGE=ON, lib/.

• Tarball: bin/, lib/ (with cmake/SilKit), include/, man pages, share/sil-kit/sil-kit-registry.service and share/doc/libsilkit/. That doc directory holds CHANGELOG.md (the release notes of the version from sil-kit docs/changelog/versions/), LICENSE and README.rst. The tarball is relocatable: the CMake config is relocatable and the utilities use $ORIGIN RPATHs.
• Debug tarball: lib/debug/.build-id/xx/yyyy.debug, produced with dwz and objcopy --only-keep-debug, plus a gnu-debuglink. Use it in gdb with set debug-file-directory.
• Toolchains: gcc 9 (Ubuntu 20.04), devtoolset-11 (el7), gcc-toolset-12 (el8). The binaries only need the libstdc++ of the target distribution.
• Reproducible:
  • SOURCE_DATE_EPOCH is the sil-kit commit time.
  • Archive entries are sorted, owned by root and have normalized modes.
  • The gzip header carries no name or time.
  • -ffile-prefix-map maps the build paths away; debian/rules gets reproducible=+fixfilepath.

Workflow (package-silkit.yml)

• Inputs:
  • silkit_ref: a pinned sha or tag.
  • pkg_sha: the run fails if the dispatched ref is at another commit.
  • expected_version: checked against debian/changelog, the rpm spec and the sil-kit sources.
  • correlation_id: shown in the run name.
  • The maintainer defaults to the one in debian/control (this also fixes DEBEMAIL being set from the name).
• Jobs: targets → package (matrix) → test (matrix, in the plain test_image via tests/run_package_test.sh) → collect.
• The build uses docker run instead of a job container, because the actions (node 20) do not run inside CentOS 7.
• Artifact sil-kit-pkg, kept 30 days:
  • all assets
  • pkg-manifest.json with the sil-kit sha and submodules, the pkg sha, the image digests, and sha256/size/release per file
  • SHA256

rebuild-check.yml (weekly or by dispatch) builds everything twice and compares the sha256 of all files. On a difference it attaches a diffoscope report.

The legacy .github/actions (debian:sid docker action) is removed.

Tested locally

Tested with podman, with the images from #62 and sil-kit v5.0.8. Each build was followed by the test in the plain distribution image: the package installs or extracts, find_package(SilKit) works, the registry starts and the test participant connects.

Target	Result	Size
Ubuntu 20.04 deb	ok	debs as in the 5.0.8 release (1.16 MB / 94 KB / 817 KB), ddeb 24.7 MB
Ubuntu 20.04 tgz	ok
el7 tgz in centos:7	ok	3.7 MB, debug 45.9 MB
el8 tgz in almalinux:8	ok	3.6 MB, debug 46.4 MB

The debug tarballs are bigger than the clang-built ddeb, because gcc writes more DWARF. Almost all of it is libSilKit.so. The arm64 deb, the el9 rpm and the workflows themselves can only be tested by CI.

After merging #62

The images are referenced as :main. After #62 has published them, pin them by digest in release/packages.json (the digests are in the summary of the Build Images run). After that, run the workflow once manually with silkit_ref=v5.0.8.

🤖 Generated with Claude Code

[KonradBreitsprecherBkd]

Reproducibility checked locally: the el8 tarball was built twice, in separate containers and at different times, from sil-kit v5.0.8. Both builds are bit-identical:

21156df27372c3a239d02ce1cf6bbc57a6edb7e483420b28217afcd4f07edf57  libsilkit-5.0.8.el8.x86_64.tar.gz
466193ead9ab0234a29c2bd13febcae18d61379d628c63209e884e3dfa30745a  libsilkit-5.0.8.el8.x86_64.debug.tar.gz

Both builds used the same mount path, so the path mapping was not exercised. rebuild-check.yml will cover the other targets and different runners.

[snps-fiodorov]

Could you please add a release for Alma 8 on Arm?

I didn't go through the details as I trust it all works and I see it's even tested in containers.

The only suggestion is to use the SilKit-5.0.8-ubuntu-22.04-x86_64-gcc.zip naming schema for tarballs, because they also contain the utils, not just the silkit library.

This is not relevant for me, but out of curiosity, why do we need ubuntu 20.04 as it's not supported by Ubuntu?

[KonradBreitsprecherBkd]

Could you please add a release for Alma 8 on Arm?

I didn't go through the details as I trust it all works and I see it's even tested in containers.

The only suggestion is to use the SilKit-5.0.8-ubuntu-22.04-x86_64-gcc.zip naming schema for tarballs, because they also contain the utils, not just the silkit library.

This is not relevant for me, but out of curiosity, why do we need ubuntu 20.04 as it's not supported by Ubuntu?

@snps-fiodorov (FYI @MarkusMhg )
This is now fully self contained. You can define images and add releases in the package.json. We created a structure to enable everyone to contribute and I'm really not the expert on linux distributions, so I would suggest you extend this PR to add Alma 8 on Arm.

[snps-fiodorov]

We created a structure to enable everyone to contribute

That's even better. Then I can add the Alma on Arm in a subsequent PR.

What do you think about my package naming suggestion?

[KonradBreitsprecherBkd]

Could you please add a release for Alma 8 on Arm?

I didn't go through the details as I trust it all works and I see it's even tested in containers.

The only suggestion is to use the SilKit-5.0.8-ubuntu-22.04-x86_64-gcc.zip naming schema for tarballs, because they also contain the utils, not just the silkit library.

(FYI @MariusBgm)
The SilKit-…-gcc.zip files are the CPack zips from sil-kit's own CI. These tarballs are separate and come out as libsilkit-5.0.8.el8.x86_64.tar.gz and so on. I went with libsilkit-<version>.<platform>.<arch> to match the deb/rpm naming. But you're right, the lib prefix is misleading, what about just silkit-<version>.<platform>.<arch>?

This is not relevant for me, but out of curiosity, why do we need ubuntu 20.04 as it's not supported by Ubuntu?

The .deb packages are build on 20.04 because binaries built against its older glibc also run on newer releases. So the debs work on 20.04, 22.04, 24.04 and Debian. To have a symmetric tarball, I uesd 20.04.

[snps-fiodorov]

@KonradBreitsprecherBkd ,

what about just silkit-<version>.<platform>.<arch>?

sounds good