Skip to content
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

Closed
joniw opened this issue Aug 23, 2023 · 3 comments · Fixed by #29137
Closed

Alpine Package Registry: Handling of 'noarch' packages #26691

joniw opened this issue Aug 23, 2023 · 3 comments · Fixed by #29137

Comments

@joniw
Copy link

joniw commented Aug 23, 2023

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:

root@alpine-dev ~/test # wget https://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/salt-3006.2-r0.apk
Connecting to dl-cdn.alpinelinux.org ([2a04:4e42:6f::644]:443)
saving to 'salt-3006.2-r0.apk'
salt-3006.2-r0.apk   100% |**************************************************************************************************************************| 5625k  0:00:00 ETA
'salt-3006.2-r0.apk' saved
root@alpine-dev ~/test # curl --user testuser:password --upload-file salt-3006.2-r0.apk https://[***REDACTED***]/api/packages/alpine-packages/alpine/edge/
root@alpine-dev ~/test # apk update
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
fetch https://[***REDACTED***]/api/packages/alpine-packages/alpine/edge/salt/x86_64/APKINDEX.tar.gz
WARNING: updating and opening https://[***REDACTED***]/api/packages/alpine-packages/alpine/edge/salt: No such file or directory
v3.18.3-55-g2ee93b9273a [https://dl-cdn.alpinelinux.org/alpine/v3.18/main]
v3.18.3-63-g5d6ac0a2673 [https://dl-cdn.alpinelinux.org/alpine/v3.18/community]
2 unavailable, 0 stale; 20063 distinct packages available
root@alpine-dev ~/test # wget https://[***REDACTED***]/api/packages/alpine-packages/alpine/edge/salt/x86_64/APKINDEX.tar.gz
Connecting to [***REDACTED***] ([***REDACTED***]:443)
wget: server returned error: HTTP/1.1 404 Not Found
root@alpine-dev ~/test # wget https://[***REDACTED***]/api/packages/alpine-packages/alpine/edge/salt/noarch/APKINDEX.tar.gz
Connecting to [***REDACTED***] ([***REDACTED***]:443)
saving to 'APKINDEX.tar.gz'
APKINDEX.tar.gz      100% |**************************************************************************************************************************|  1170  0:00:00 ETA
'APKINDEX.tar.gz' saved

Possible solutions to this problem from my point of view are:

  • add 'noarch' packages to all architectures
  • allow to set the architecture on upload

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

@serenevoid
Copy link

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 noarch packages into all the architectures supported by alpine. But that might cause data redundancy if I understood it correctly. So what if I try to make the Download function search the package in noarch once if the package is not found in the respective arch folder. Will that be a good solution?

@joniw
Copy link
Author

joniw commented Sep 21, 2023

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.

@joniw
Copy link
Author

joniw commented Jan 11, 2024

Just a small workaround for other people who have problems with this issue:

TARGET_ARCH=x86_64
for apk in $(find /path/to/apks -type f -name "*.apk"); do
    tmp=$(mktemp -dup /tmp);
    mkdir -p ${tmp}/apk && chmod -R 0755 ${tmp};
    tar -xzpf ${apk} -C ${tmp}/apk;
    rm ${tmp}/apk/.SIGN*.pub;
    mv ${tmp}/apk/.PKGINFO ${tmp};
    tar -C ${tmp}/apk/ --xattrs -f - -c $(ls -A1 ${tmp}/apk) | abuild-tar --hash | gzip -9 > ${tmp}/data.tar.gz;
    sha256=$(sha256sum ${tmp}/data.tar.gz | cut -d" " -f1);
    sed -i "\$d" ${tmp}/.PKGINFO;
    echo "datahash = ${sha256}" >> ${tmp}/.PKGINFO;
    echo "Rewriting architecture for $(basename ${apk}) to ${TARGET_ARCH}";
    sed -i "s/arch = noarch/arch = ${TARGET_ARCH}/g" ${tmp}/.PKGINFO;
    tar -C ${tmp} -f - -c .PKGINFO | abuild-tar --cut | gzip -9 > ${tmp}/control.tar.gz;
    abuild-sign ${tmp}/control.tar.gz;
    cat ${tmp}/control.tar.gz ${tmp}/data.tar.gz > ${apk};
    rm -rf ${tmp};
done

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:

  • *-doc
  • *-openrc
  • *-lang
  • *-lang-*
  • *sh-completion
  • *-pyc

lunny added a commit that referenced this issue Feb 25, 2024
…9137)

Fixes #26691
Revert #24972

The alpine package manager expects `noarch` packages in the index of
other architectures too.

---------

Co-authored-by: Lauris BH <lauris@nix.lv>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants