pulp
metadata in a synced NVIDIA repository is wrong
A repository[0] contains a package with the name nsight-systems-2025.3.2-2025.3.2.474_3638932-0.x86_64.rpm. However, the metadata in the package does not match the version in the filename:
$ rpm -qip nsight-systems-2025.3.2-2025.3.2.474_3638932-0.x86_64.rpm
Name : nsight-systems-2025.3.2
Version : 2025.3.2.474_253236389321v0
This results in Pulp publishing the package with it's original file name but the repodata directory contains a reference to it using the information from above. This makes it impossible to install this package from Pulp.
I was able to work around this by
- Remove the package from the repository versions that contain it
- Cleanup orphans
- Upload the package to Pulp.
- Add package to the repository again.
This resulted in the package being published with the name nsight-systems-2025.3.2-2025.3.2.474_253236389321v0-0.x86_64.rpm.
I expect the behavior of sync to be the same as upload.
[0] https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/
Some clarification from a discussion in Matrix:
- The NVR of the file in the upstream is name: systems-2025.3.2 , version: 474_253236389321v0, release: 0.
- The location_href in the upstream repo is nsight-systems-2025.3.2-2025.3.2.474_3638932-0.x86_64.rpm (which is NOT the N-V-R.A.rpm)
- Doing a "regular" sync, Pulp uses the upstream-location, but publishes a new primary.xml with the "assumption" that the location-href should be N-V-R.A.rpm, so the file isn't "findable" from the generated primary.xml
Upload fixes this because that path enforces filename == RPM metadata N-V-R.A.rpm
Can you provide details about:
- sync_policy: additive | mirror_content_only | mirror_complete
- remote policy: on_demand | immediate
- core and rpm version used
Feels like it might be related to https://github.com/pulp/pulp_rpm/pull/4070
I did not specify a sync policy at sync time. So I suspected it is additive. Remote policy is immediate.
"rpm": "3.32.5",
"core": "3.91.1",
We are impacted by this as well:
https://github.com/microsoft/linux-package-repositories/issues/280
We're on pulpcore 3.88.0 and pulp-rpm 3.32.2.
~We are affected by a similar issue on the mft package by mellanox (also NVIDIA by proxy): https://linux.mellanox.com/public/repo/doca/3.1.0/rhel9.6/aarch64/mft-4.33.0-169.arm64.rpm~
~This is specifying mft-4.33.0-169.arm64.rpm as package name. Within the package data, it is correctly identified as aarch64 in the package metadata. We are not using a sync, but downloading the packages and then uploading them to the pulp repository afterwards. The package can be located under the relative path /Packages/m/mft-4.32.0-120.arm64.rpm, however the package metadata shows:~
<package type="rpm">
<name>mft</name>
<arch>aarch64</arch>
<version epoch="0" ver="4.32.0" rel="120"/>
<checksum type="sha256" pkgid="YES">947110117627542bb3429e176ea6641c61a8ab96704bad9a600f4e55905c3da5</checksum>
<summary>Mellanox firmware tools</summary>
<description>Mellanox firmware tools</description>
<packager>Omer Dagan <[email protected]></packager>
<url></url>
<time file="1746525027" build="1746004881"/>
<size package="62027432" installed="194302547" archive="194364616"/>
<location href="Packages/m/mft-4.32.0-120.aarch64.rpm"/>
...
Therefore one cannot install this package via dnf install.
We are currently on pulp-rpm 3.33.0 and pulpcore 3.91.1
Edit: nevermind, this seems to be fixed by rpm-datarepair 4073
Edit: nevermind, this seems to be fixed by rpm-datarepair 4073
Excellent news. Yes, for future reference, this is intended to be the correct fix. There's also now a --dry-run option which was added recently, so that you can verify that the affected packages will be fixed prior to doing any changes to the data itself.
I'm gonna guess the closure as part of that foreman_maintain issue was some GH automated weirdness, shall we reopen this?
