Installing package dependencies from RPM Package Repo fails #11644

Closed
opened 2025-11-02 09:43:19 -06:00 by GiteaMirror · 3 comments
Owner

Originally created by @mehmax on GitHub (Sep 13, 2023).

Description

I have uploaded some rpm packages to my Gitea instance. Some of those packages have dependencies which are uploaded as well to the gitea package repo.

I have added my package repo to dnf.

# packages.rpm.distro.redhat
dnf config-manager --add-repo http://XXXX:3000/api/packages/cloned/rpm.repo

But have modified the /etc/yum.repos.d/rpm.repo and disabled gpgcheck

[gitea-cloned]
name=cloned - Gitea: Git with a cup of tea
baseurl=http://XXXX:3000/api/packages/cloned/rpm
enabled=1
gpgcheck=0
gpgkey=http://XXXX:3000/api/packages/cloned/rpm/repository.key

I have uploaded the required packages

image

Due to simplification I now use Package 1 and Package 2
Package 1 is dependend on Package 2.

When trying to install Package 1 with dnf it correctly resolves dependencies and the source repository, but install fails due to checksum mismatch.
image

I did a bit of further analysis and found out that the filename of the downloaded file might be the reason.
All packages that are / were downloaded have the same filename x86_64.

When trying to install just from cache I see this error.
image

dnf is always refering to the same filename x86_64 even if the package name is different.

Downloading the packages manually with wget also outputs filename (which is the last part of the URL)

wget http://XXXX:3000/api/packages/cloned/rpm/package/package-1/1.0/x86_64

image

Now I dont know where the rootcause is. Is gitea outputting a "wrong" filename or is dnf

A few more annotations:

  • Installing each package without dependencies one by one is working fine
  • using yum instead of dnf results in the same error behaviour
  • using yumdownloader --resolve package-1 also outputs a single file named x86_64

Gitea Version

1.20.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

How are you running Gitea?

On-Premise with executable (no docker)

dnf version 4.0.9

Database

MySQL/MariaDB

Originally created by @mehmax on GitHub (Sep 13, 2023). ### Description I have uploaded some rpm packages to my Gitea instance. Some of those packages have dependencies which are uploaded as well to the gitea package repo. I have added my package repo to dnf. ``` # packages.rpm.distro.redhat dnf config-manager --add-repo http://XXXX:3000/api/packages/cloned/rpm.repo ``` But have modified the `/etc/yum.repos.d/rpm.repo` and disabled gpgcheck ``` [gitea-cloned] name=cloned - Gitea: Git with a cup of tea baseurl=http://XXXX:3000/api/packages/cloned/rpm enabled=1 gpgcheck=0 gpgkey=http://XXXX:3000/api/packages/cloned/rpm/repository.key ``` I have uploaded the required packages ![image](https://github.com/go-gitea/gitea/assets/84371809/df1534ec-64fe-4265-8ddd-2c0f21ea5602) Due to simplification I now use Package 1 and Package 2 Package 1 is dependend on Package 2. When trying to install Package 1 with dnf it correctly resolves dependencies and the source repository, but install fails due to checksum mismatch. ![image](https://github.com/go-gitea/gitea/assets/84371809/336b9fec-f079-4131-be63-a8b3e3560c78) I did a bit of further analysis and found out that the filename of the downloaded file might be the reason. All packages that are / were downloaded have the same filename `x86_64`. When trying to install just from cache I see this error. ![image](https://github.com/go-gitea/gitea/assets/84371809/8259d05a-a029-4f07-830f-ca3fc6dd3af0) dnf is always refering to the same filename `x86_64` even if the package name is different. Downloading the packages manually with `wget` also outputs filename (which is the last part of the URL) `wget http://XXXX:3000/api/packages/cloned/rpm/package/package-1/1.0/x86_64` ![image](https://github.com/go-gitea/gitea/assets/84371809/27c15f5f-277a-4711-894c-e0b75ca1a6d1) Now I dont know where the rootcause is. Is gitea outputting a "wrong" filename or is dnf A few more annotations: - Installing each package without dependencies one by one is working fine - using `yum` instead of `dnf` results in the same error behaviour - using `yumdownloader --resolve package-1` also outputs a single file named `x86_64` ### Gitea Version 1.20.3 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System ``` NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" ``` ### How are you running Gitea? On-Premise with executable (no docker) ``` dnf version 4.0.9 ``` ### Database MySQL/MariaDB
GiteaMirror added the topic/packagestype/bug labels 2025-11-02 09:43:19 -06:00
Author
Owner

@ExplodingDragon commented on GitHub (Sep 13, 2023):

This is a bug , because dnf can't properly parse the filename in the request header.

It is possible to temporarily add a new virtual route to alleviate the error.

17693fbab0/routers/api/packages/api.go (L522)

@ExplodingDragon commented on GitHub (Sep 13, 2023): This is a bug , because dnf can't properly parse the filename in the request header. It is possible to temporarily add a new virtual route to alleviate the error. https://github.com/go-gitea/gitea/blob/17693fbab0b2b3194f1f610804eeb2aa08335e92/routers/api/packages/api.go#L522
Author
Owner

@Leskodamus commented on GitHub (Oct 24, 2023):

Having the same issue and hoping for a fix as it would be nice to auto install dependencies in production.

@Leskodamus commented on GitHub (Oct 24, 2023): Having the same issue and hoping for a fix as it would be nice to auto install dependencies in production.
Author
Owner

@ExplodingDragon commented on GitHub (Jan 12, 2024):

Note: After upgrading to the latest version you need to upload a new RPM to refresh the index before it will work.

@ExplodingDragon commented on GitHub (Jan 12, 2024): Note: After upgrading to the latest version you need to upload a new RPM to refresh the index before it will work.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#11644