Skip to content

Conversation

@cognifloyd
Copy link
Member

@cognifloyd cognifloyd commented Nov 21, 2025

PR Series Overview

This is the fourth (and final) in a series of PRs that introduces a new backend: pants.backend.npm.native_libs
Initially, the backend will be available as: pants.backend.experimental.nfpm.native_libs

I proposed this new backend (originally named bindeps) in discussion #22396.

This backend will inspect ELF bin/lib files (like lib*.so) in packaged contents (for this PR series, only in pex_binary targets) to identify package dependency metadata and inject that metadata on the relevant nfpm_deb_package or nfpm_rpm_package targets. Effectively, it will provide an approximation of these native packager features:

  • rpm: rpmdeps + elfdeps
  • deb: dh_shlibdeps + dpkg-shlibdeps (These substitute ${shlibs:Depends} in debian control files have)

Goal: Host-agnostic package builds

This pants backend is designed to be host-agnostic, like nFPM.

Native packaging tools are often restricted to a single release of a single distro. Unlike native package builders, this new pants backend does not use any of those distro-specific or distro-release-specific utilities or local package databases. This new backend should be able to run (help with building deb and rpm packages) anywhere that pants can run (MacOS, rpm linux distros, deb linux distros, other linux distros, docker, ...).

Previous PRs in series

PR Overview

TODO:

  • finish this description
  • add reviewers

NOTE on using SOInfo dataclass:

We need slightly different things for deb vs rpm. For deb, we need just
the soname to search for relevant packages, and parsing the so_info
string did not seem wise when I can just preserve the data as elfdeps
returned it. So, we now have a SOInfo dataclass (a limited mirror of the
elfdeps.SOInfo dataclass).
I reviewed dh_shlibdeps and dpkg-shlibdeps sources so that we can do
something similar without all the heavy-weight baggage of native tooling
(which includes a complete installation of a specific distro release,
because dpkg-shlibdeps uses symbols and shlibs files from other
installed packages to identify packages that provide required sonames.)

The whole point of nfpm is to be able to build the package for any
version of a distro on any version of that distro or some other distro
or even on a different OS. So, we necessarily cannot replicate all of
the dpkg-shlibdeps logic, but we can do quite a bit thanks to the
package search API.
We need to select the relevant package(s) based on the .so file path,
following (a simplified set of) standard LD lookup rules.
This commit updates the deb_search_for_sonames script and rule
so that .so file names are available for that selection process.
This only adds package dependencies without any version constraints.
It might be possible to add a version constraint based on the so_version.
But, this is good enough for now.
This encapsulates the logic, based on dpkg-shlibdeps, that filters SONAMEs.
And give the tests more time (API calls can be flaky and retries take time.
But once cached, the test shouldn't repeat).
Add these fields to the `nfpm_deb_package` target:
- `distro`
- `distro_codename`

These are required as input parameters for this script:
- `pants.backend.nfpm.native_libs.deb.search_for_sonames`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants