Duplicate RPM packages in rpm.grafana.com under both Package and Packages

Grafana Installation
1

Hi,

it looks like the RPM repository at rpm.grafana.com currently contains four duplicate packages that exist in two different locations.

The affected packages are:

grafana-enterprise-10.1.0-1.aarch64.rpm
grafana-enterprise-10.1.0-1.arm.rpm
grafana-enterprise-10.1.0-1.armhfp.rpm
grafana-enterprise-10.1.0-1.x86_64.rpm

These packages appear to be present both under:

https://rpm.grafana.com/Package/

and:

https://rpm.grafana.com/Packages/

As far as I can tell, these four RPMs are also the only packages located under Package/ without the trailing s. This makes it seem likely that the files under Package/ are either outdated or were not intended to remain there.

This causes issues for tools such as Red Hat Satellite or Pulp (standalone) when mirroring the repository for offline use. They detect these as duplicate packages and fail during repository synchronization.

Is there a specific reason why these four packages are available in a separate Package/ directory as duplicates?

Reproducer:

$ primary=$(curl -s  https://rpm.grafana.com/repodata/repomd.xml | grep -oE "repodata/[a-f0-9]+-primary.xml.gz") && curl -s "https://rpm.grafana.com/${primary}" | zgrep -E "Packages?/grafana-enterprise-10.1.0-1" | sort
  <location href="Package/grafana-enterprise-10.1.0-1.aarch64.rpm"/>
  <location href="Package/grafana-enterprise-10.1.0-1.armhfp.rpm"/>
  <location href="Package/grafana-enterprise-10.1.0-1.arm.rpm"/>
  <location href="Package/grafana-enterprise-10.1.0-1.x86_64.rpm"/>
  <location href="Packages/grafana-enterprise-10.1.0-1.aarch64.rpm"/>
  <location href="Packages/grafana-enterprise-10.1.0-1.armhfp.rpm"/>
  <location href="Packages/grafana-enterprise-10.1.0-1.arm.rpm"/>
  <location href="Packages/grafana-enterprise-10.1.0-1.x86_64.rpm"/>

Thanks!

2

you can try
Duplicate remove then Rebuild metadata
or
Ignore Package/ path
not sure but you can try this.
thanks

3

In our case (we use Red Hat Satellite), it is not possible to ignore specific paths. The initial sync fails as early as the metadata parsing stage because duplicate packages are found, which should not happen.
I’m not sure, but the problem would likely occur with any other software built on top of Pulp as well.

4

We were able to work around the issue on Red Hat Satellite/Pulp with the following approach:

  1. Download the repository locally using reposync (restricting to the required architectures only):
reposync \
  --repoid=grafana \
  --download-path=/local/path \
  --arch=x86_64 \
  --arch=noarch
  1. Check for duplicate RPM filenames:
find /local/path -name "*.rpm" \
| sed 's#.*/##' \
| sort \
| uniq -d
  1. Verify the duplicate files had identical checksums:
sha256sum $(find /local/path -name "grafana-enterprise-10.1.0-1.x86_64.rpm")

In our case, the RPMs under Package/ and Packages/ were identical.

  1. Remove the duplicate Package/ directory:
rm -rf /local/path/grafana/Package
  1. Upload the RPMs manually into a custom Satellite repository:
hammer repository upload-content \
  --organization "ORG" \
  --product "Grafana" \
  --name "grafana-local" \
  --path /local/path/grafana/Packages

After removing the duplicate path and uploading the RPMs directly, Pulp/Satellite generated metadata successfully and the repository worked normally.

So the issue does appear to be specifically related to the duplicate Package/ entries present in the upstream repository metadata.

One additional note: this workaround takes quite a long time, especially during the upload-content step, since Satellite/Pulp processes RPMs individually. However, the process completed successfully and allowed us to publish the repository normally.

5

That’s exactly what we did.

It would be better, though, if the upstream repo were fixed.