Update pin for libsystemd

[regro-cf-autotick-bot]

This PR has been triggered in an effort to update the pin for libsystemd. The current pinned version is 257, the latest available version is 258 and the max pin pattern is x. This migration will impact 4 feedstocks.

Checklist:

• The new version is a stable supported pin.
• I checked that the ABI changed from 257 to 258.

**Please note that if you close this PR we presume that the new pin has been rejected.

@conda-forge-admin please ping systemd

_{This PR was generated by https://github.com/regro/cf-scripts/actions/runs/19178197069 - please use this URL for debugging.}

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-webservice.

I was asked to ping @conda-forge/systemd and so here I am doing that.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[hmaarrfk]

any words of wisdom for a way forward?

[ryanvolz]

See #7939, but in summary: v257 is the last one we're currently able to build against c_stdlib 2.17, so we have a global pin now to keep things building against that instead of the newer versions that get released with compatibility only with c_stdlib 2.34.

[h-vetinari]

Wow, that is quite the jump in the glibc lower bound. 😮

I think we have to figure out a way to be able to build newer libsystemd; given how low-level systemd is (and thus regularly affected by CVEs), we cannot stay stuck for years on v257, and it would indeed be years.

This is exactly the security-vs-compatibility issue I was lamenting in conda-forge/cdt-builds#89. The "obvious" answer (with current technology) would be to zip libsystemd together with c_stdlib_version, but that's not sustainable. We'd need to come up with a better way infrastructurally to do these things.

We have similar issues on macos (xref), where a lot of libraries are beginning to require newer deployment targets than our baseline, most prominently abseil, protobuf, qt, etc. See also this comment.

[ryanvolz]

It's maybe not so dire in this particular situation. Let me expand:

1. Out of all of systemd, we are currently only building libsystemd and libudev. I don't know what exactly that results in security-wise, but it's a much more limited scope than what you might be thinking of for systemd.
2. The ABI of libsystemd and libudev are very stable, so building against the older version still allows using the newer version where the underlying system supports the required system libraries.
3. The package actually only needs the kernel headers that come wrapped up in the sysroot, and not anything glibc as far as I know. So perhaps there is a way forward that involves just using the newer kernel headers to do the build while still maintaining compatibility with the older sysroot. I think that's what we'd end up doing anyway by patching systemd to add specific missing header definitions to make it build (as I've already had to do somewhat up to this point).