fix: Align xrpld RPM packaging with DEB package#7529
Conversation
cfc80fb to
497fb2a
Compare
|
This PR has conflicts, please resolve them in order for the PR to be reviewed. |
497fb2a to
a61534e
Compare
|
All conflicts have been resolved. Assigned reviewers can now start or resume their review. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #7529 +/- ##
=========================================
- Coverage 82.0% 81.9% -0.0%
=========================================
Files 1007 1007
Lines 76876 76854 -22
Branches 8982 8984 +2
=========================================
- Hits 63003 62979 -24
- Misses 13864 13866 +2
Partials 9 9 🚀 New features to boost your workflow:
|
mathbunnyru
left a comment
There was a problem hiding this comment.
Approved, if it will take less time in CI (please, check, when it's done)
mathbunnyru
left a comment
There was a problem hiding this comment.
Unfortunately, doesn't work:
PR / package / xrpld-rhel-gcc-release-amd64 (pull_request)Successful in 12m
a61534e to
d1fd10e
Compare
I saw that. I removed the knobs but I removed the thing that made it work also. Re-running. |
d1fd10e to
3961412
Compare
3961412 to
7740ee6
Compare
|
This brings RPM package validation into the same rough size/time class as Debian. For context:
The old RPM artifact was smaller, but it got there by spending about 10 extra minutes optimizing/compressing debug-package payloads for a disposable CI artifact. Debian is already the practical comparison point here: DWZ optimization is not viable there for Operationally, the debug-symbol packages are mostly useful when we need to analyze coredumps. The download data supports optimizing this path for CI latency rather than RPM debug artifact size.
Some of the debian debug downloads were us also. So for PR validation, I think it is reasonable to optimize for fast proof that the package builds rather than spending another ~10 minutes minimizing a short-lived RPM debug artifact that is rarely consumed. |
|
Almost as fast as deb now |
| Name: xrpld | ||
| Version: %{xrpld_version} | ||
| Release: %{xrpld_release}%{?dist} | ||
| Version: %{pkg_version} | ||
| Release: %{pkg_release}%{?dist} |
| if [[ "${XRPLD_VERSION}" == -* || "${XRPLD_VERSION}" == *- ]]; then | ||
| echo "build_pkg.sh: invalid XRPLD_VERSION='${XRPLD_VERSION}'." >&2 | ||
| echo "Version cannot start or end with '-'." >&2 | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
Why do we check these specific conditions?
There was a problem hiding this comment.
Good catch. If we got here we've gotten past BuildInfo's constraints, shouldn't be possible by the time packaging sees it.
| # changelog's third field "distribution", but the suite/codename (noble, | ||
| # bookworm, ...) is assigned by the publishing infra at ingest; this |
There was a problem hiding this comment.
Just in case - we don't and won't build for different codenames.
It's because we build with a custom century-old libc
There was a problem hiding this comment.
Yep, this was a wording issue. I removed the implication that packaging is selecting or supporting Debian/Ubuntu codenames. The changelog distribution value is just the XRPLF release channel we publish to (stable, develop, unstable), not the build host codename.
| # changelog's third field "distribution", but the suite/codename (noble, | ||
| # bookworm, ...) is assigned by the publishing infra at ingest; this | ||
| # suite-agnostic build only sets the component. RPM has no equivalent. | ||
| # 3.2.0 -> stable, *-b0[+metadata] -> develop, other pre-release -> unstable. |
There was a problem hiding this comment.
Maybe let's mention RCs here as well?
They are far more important than betas
There was a problem hiding this comment.
Added RCs explicitly. The docs/comment now call out that non-b0 prereleases, including beta and RC builds, go to unstable.
| xrpld.sysusers sysusers.d config (used by both RPM and DEB) | ||
| xrpld.tmpfiles tmpfiles.d config (used by both RPM and DEB) | ||
| xrpld.logrotate logrotate config (installed to /etc/logrotate.d/xrpld) | ||
| 50-xrpld.preset systemd preset (RPM only; DEB enables the unit via dh_installsystemd) |
There was a problem hiding this comment.
Should be in rpm dir if it's only used in rpm
There was a problem hiding this comment.
Let's just remove it altogether since it's one line!
| | Package type | Image (`package_configs.<distro>[].image` in `linux.json`) | Tools required | | ||
| | ------------ | ---------------------------------------------------------- | ---------------------------------------------- | | ||
| | RPM | `ghcr.io/xrplf/xrpld/packaging-rhel:sha-<sha>` | `rpmbuild` | | ||
| | DEB | `ghcr.io/xrplf/xrpld/packaging-debian:sha-<sha>` | `dpkg-buildpackage`, `debhelper-compat (= 13)` | |
There was a problem hiding this comment.
Probably anything >= 13 would work.
There was a problem hiding this comment.
Changed the wording.
Probably this CMake could work right? 😸
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED OFF)| The version is not a CMake input on this path: `cmake/XrplVersion.cmake` reads | ||
| it from `src/libxrpl/protocol/BuildInfo.cpp` into `xrpld_version`, and |
There was a problem hiding this comment.
You have more than 1 way of determining xrpld version.
Can we leave just one, please?
I think ./xrpld --version with a bit of parsing should be fine - you have the binary in places where you need it.
There was a problem hiding this comment.
Love it.
Packaging derives the version from the binary, just fail early if ${BUILD_DIR}/xrpld is missing or not executable, before trying to parse version. That makes the "you must already have a binary" contract obvious.
|
I think this stopped being trivial, to be honest, so requires 2 approvals, and it's not ready to merge yet |
I think so too. 🤕 |
The DEB package already skips the dwz debug optimization step because it takes a long time. This change brings RPM package validation into the same rough size/time class as Debian package generation.
Changes:
XRPLD_VERSION) stays distinct from the normalized package metadata version (pkg_version).For context from CI validation:
The old RPM artifact was smaller, but it spent about 10 extra minutes optimizing/compressing debug-package payloads for a short-lived CI artifact. Debian is already the practical comparison point here: DWZ optimization is not viable there for
xrpldtoday (Too many DIEs, not optimizing), and the Debian debug package still builds quickly.Operationally, debug-symbol packages are mostly useful when analyzing coredumps. The download data supports optimizing this path for CI latency rather than RPM debug artifact size. For
3.1.3, the stats were:Some of the Debian debug downloads were us too.