getdeps: add distro_family and recognise Red Hat Enterprise Linux - #495
Closed
michel-slm wants to merge 1 commit into
Closed
michel-slm wants to merge 1 commit into
michel-slm wants to merge 1 commit into
Conversation
get_linux_type() derives the distro name from NAME in /etc/os-release,
which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing
knows that name: HostType.get_package_manager() returns None for it, so
--allow-system-packages silently satisfies nothing and every dependency
is built from source, and the manifests with distro=centos_stream
selectors do not apply either. RHEL's VERSION_ID also carries a minor
("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would
miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a
buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and
the local mock configs use centos-stream-release. A getdeps-based EPEL 9
build therefore behaves differently in Koji than in local mock. Nobody
noticed because getdeps has not been used for distro packaging before
and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests
actually mean. Following Chef's platform_family, introduce a
distro_family alongside distro: "rhel" for rhel, centos, centos_stream,
alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint;
"arch". Fedora is deliberately its own family, unlike Ansible's
os_family which folds it into RedHat: its base repositories carry many
dependencies that the EL family only has in EPEL or not at all (glog,
gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is
zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen
manifest sections already select on exactly that difference.
Concretely:
- RHEL reports distro "rhel", the same short name as its os-release ID;
- within the rhel family distro_vers is the major version only, so
RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS
Stream 9 does; Fedora and Ubuntu keep their full versions;
- distro_family is available to manifest selectors and drives
get_package_manager(), which now returns rpm for the whole rhel
family;
- `install-system-deps --distro` accepts rhel;
- os-release parsing moves into parse_os_release() so it can be unit
tested.
Existing selectors keep their meaning: distro=centos_stream still
matches only CentOS Stream. A follow-up will switch the sections that
mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick
up gcc-toolset, libaio and numactl too. Until then a RHEL host already
gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux
--distro rhel --distro-version 9 cachelib` now produces a dnf command
(previously "I don't know how to install any packages on this system"),
and unit tests cover the os-release parsing for Fedora, CentOS Stream,
RHEL, Alma, Rocky and Ubuntu plus the family and package-manager
mapping. Verified against synthetic os-release contents, not a live
RHEL host.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: Michel Lind <salimma@fedoraproject.org>
meta-cla
Bot
added
the
CLA Signed
Contributor
|
@michel-slm has imported this pull request. If you are a Meta employee, you can view this in D120501703. |
meta-codesync Bot
pushed a commit
that referenced
this pull request
Sep 17, 2026
…494) Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to #488 and #493. RHEL hosts only benefit once #495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Pull Request resolved: #494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/fb303
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/wangle
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/BGP
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/openr
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebookexperimental/edencommon
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/folly
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebookexperimental/rust-shed
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebookincubator/hsthrift
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/rebalancer
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebookincubator/fizz
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/fbthrift
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/mvfst
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/watchman
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/sapling
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/hhvm
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebookincubator/katran
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/fboss
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/wangle
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebook/fb303
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebook/openr
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebook/mvfst
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebookexperimental/rust-shed
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebook/folly
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebook/hhvm
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebook/fbthrift
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebook/fboss
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebook/fboss
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebookexperimental/moxygen
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebookexperimental/moxygen
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebookexperimental/moxygen
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebookincubator/fizz
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in #488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in #488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once #495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Pull Request resolved: #497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/wangle
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebookincubator/hsthrift
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebookincubator/katran
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebookincubator/katran
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/fb303
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/mvfst
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebookexperimental/rust-shed
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/BGP
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/fbthrift
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/folly
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/openr
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/sapling
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebookexperimental/edencommon
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/rebalancer
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/watchman
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/hhvm
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
meta-codesync Bot
pushed a commit
to facebook/proxygen
that referenced
this pull request
Sep 17, 2026
Summary: Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself. The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl. Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs. Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) X-link: facebook/CacheLib#494 Reviewed By: likewhatevs Differential Revision: D120501594 Pulled By: michel-slm fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot
pushed a commit
to facebook/proxygen
that referenced
this pull request
Sep 17, 2026
Summary:
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; - `install-system-deps --distro` accepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.
Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested: `install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelib` now produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.
A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to `distro_family=rhel`; it must land after this one because the expression parser rejects unknown selector variables.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#495
Reviewed By: likewhatevs
Differential Revision: D120501703
Pulled By: michel-slm
fbshipit-source-id: f24b01e46207a08ca09b9f09500ba0fb78a502fa
meta-codesync Bot
pushed a commit
to facebook/proxygen
that referenced
this pull request
Sep 17, 2026
Summary:
Fedora retired liboqs in Fedora 45 ("Obsoleted by openssl 3.5": OpenSSL 3.5 ships ML-KEM natively), so the `[rpms.distro=fedora]` mapping added in facebook/CacheLib#488 only resolves on Fedora 44 and older. On Rawhide a build with --allow-system-packages that generates its BuildRequires from the manifests fails at dependency resolution with "No match for argument: liboqs-devel". fizz still hard-depends on liboqs, so let getdeps build it from source (or the vendor tree) on Fedora as it does everywhere else.
Found while building the Fedora cachelib package on Rawhide with BuildRequires generated from the manifests; the mapping was added in facebook/CacheLib#488 and only checked against Fedora 44 at the time. CentOS Stream 10 does ship liboqs-devel, so a `distro_family=rhel` mapping for EL 10 could be considered separately once facebook/CacheLib#495 lands.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
X-link: facebook/CacheLib#497
Reviewed By: likewhatevs
Differential Revision: D120517415
Pulled By: michel-slm
fbshipit-source-id: 1386a4418536d59a36feffb24f85f48cf19f11f3
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
get_linux_type() derives the distro name from NAME in /etc/os-release, which on Red Hat Enterprise Linux yields "red_hat_enterprise". Nothing knows that name: HostType.get_package_manager() returns None for it, so --allow-system-packages silently satisfies nothing and every dependency is built from source, and the manifests with distro=centos_stream selectors do not apply either. RHEL's VERSION_ID also carries a minor ("9.8"), as do AlmaLinux's and Rocky's, so even a matching distro would miss the distro_vers=9 selectors written for CentOS Stream.
This matters for EPEL: Fedora's Koji builds EPEL 9 packages in a buildroot with redhat-release (real RHEL), while EPEL 10 buildroots and the local mock configs use centos-stream-release. A getdeps-based EPEL 9 build therefore behaves differently in Koji than in local mock. Nobody noticed because getdeps has not been used for distro packaging before and RHEL is rare among people building from source.
Rather than pretend RHEL is CentOS Stream, model what the manifests actually mean. Following Chef's platform_family, introduce a distro_family alongside distro: "rhel" for rhel, centos, centos_stream, alma and rocky; "fedora"; "debian" for debian, ubuntu, pop!_os and mint; "arch". Fedora is deliberately its own family, unlike Ansible's os_family which folds it into RedHat: its base repositories carry many dependencies that the EL family only has in EPEL or not at all (glog, gflags, fmt, fast_float, googletest, benchmark, liboqs, jq), zlib is zlib-ng-compat there, and CentOS Stream 9 needs gcc-toolset; nineteen manifest sections already select on exactly that difference.
Concretely: - RHEL reports distro "rhel", the same short name as its os-release ID; - within the rhel family distro_vers is the major version only, so RHEL 9.8, Alma 9.6 and Rocky 9.6 all match distro_vers=9 as CentOS Stream 9 does; Fedora and Ubuntu keep their full versions; - distro_family is available to manifest selectors and drives get_package_manager(), which now returns rpm for the whole rhel family; -
install-system-deps --distroaccepts rhel; - os-release parsing moves into parse_os_release() so it can be unit tested.Existing selectors keep their meaning: distro=centos_stream still matches only CentOS Stream. A follow-up will switch the sections that mean "any EL 9" to distro_family=rhel so that RHEL, Alma and Rocky pick up gcc-toolset, libaio and numactl too. Until then a RHEL host already gains every plain [rpms] mapping and the not(distro=fedora) ones.
Tested:
install-system-deps --recursive --dry-run --os-type linux --distro rhel --distro-version 9 cachelibnow produces a dnf command (previously "I don't know how to install any packages on this system"), and unit tests cover the os-release parsing for Fedora, CentOS Stream, RHEL, Alma, Rocky and Ubuntu plus the family and package-manager mapping. Verified against synthetic os-release contents, not a live RHEL host.A follow-up PR will switch the manifest selectors that mean "any EL 9" (gcc-toolset, libaio, numactl and friends) to
distro_family=rhel; it must land after this one because the expression parser rejects unknown selector variables.🤖 Generated with Claude Code