-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alpine Package Registry: Handling of 'noarch' packages #26691
Comments
I have been looking into this for a few days now. I was initially thinking that it would be nice to implement a logic to copy and store all |
Thank you for looking into this issue. Your solution would solve the problem that the "noarch" packages are not visible, but will still serve the packages under the "noarch" architecture. An alpine repository in a directory would serve each noarch package as a distinguished one, perhabs it would be better to allow to set the target architecture on upload. |
Just a small workaround for other people who have problems with this issue:
With this code every apk is unpacked and the architecture gets rewritten. As we can see in the source the packages with the following names are always build with noarch as architecture:
|
Description
Hello,
thank you for integrating the possibility to use gitea as an alpine package registry.
When adding a package with the architecture 'noarch' (like the salt package) it can not be installed via apk.
The reason is the architecture ist automatically detected from the package in the source-code and the uploaded package is then only available under the 'noarch' archtitecture and not under the other architectures like 'x86_64'.
A short test with the salt package from edge to my gitea instance:
Possible solutions to this problem from my point of view are:
With regards
Joniw
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
No response
How are you running Gitea?
Test instance in Kubernetes
Database
PostgreSQL
The text was updated successfully, but these errors were encountered: