Feature Request - Support for Alpine APK packages #2

New Issue

claunia · 2026-01-29T16:26:51Z

claunia commented

2026-01-29 16:26:51 +00:00

Originally created by @am11 on GitHub (Jun 26, 2017).

Similar to deb and rpm; dotnet alpineapk packaging would be a great addition.
Name verbosity is to disambiguate from possible future implementation of androidapk. :)

Note that Alpine packages can be downloaded and added offline from untrusted channels:

# Almquist shell (ash)

# offline install or download from some unofficial source (e.g. GH releases or CI artifacts)
# curl -O URL_TO_APK

apk add --allow-untrusted <pkgname>

# ref - https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Add_a_local_Package

Originally created by @am11 on GitHub (Jun 26, 2017). Similar to `deb` and `rpm`; <ins>`dotnet alpineapk`</ins> packaging would be a great addition. Name verbosity is to disambiguate from possible future implementation of `androidapk`. :) Note that Alpine packages can be downloaded and added offline from untrusted channels: ```sh # Almquist shell (ash) # offline install or download from some unofficial source (e.g. GH releases or CI artifacts) # curl -O URL_TO_APK apk add --allow-untrusted <pkgname> # ref - https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Add_a_local_Package ```

claunia added the enhancement label 2026-01-29 16:26:51 +00:00

claunia commented

2026-01-29 16:26:52 +00:00

@qmfrederik commented on GitHub (Jun 26, 2017):

The package format is described here: https://wiki.alpinelinux.org/wiki/Alpine_package_format, seems somewhat similar to the package format used by Debian.

As to the feature request in itself: sure, why not, although I can't promise anything and pull requests are always welcome :)

@qmfrederik commented on GitHub (Jun 26, 2017): The package format is described here: https://wiki.alpinelinux.org/wiki/Alpine_package_format, seems somewhat similar to the package format used by Debian. As to the feature request in itself: sure, why not, although I can't promise anything and pull requests are always welcome :)

claunia commented

2026-01-29 16:26:53 +00:00

@am11 commented on GitHub (Jun 26, 2017):

For reference, here is a list of latest APKs for the distro http://dl-cdn.alpinelinux.org/alpine/latest-stable/main/x86_64/.

Would it make sense to incorporate /depend on abuild utility in the targets, that will calculate the hashes and everything (for DRY)? This way, if they change the tool in future, we won't need to refactor.

@am11 commented on GitHub (Jun 26, 2017): For reference, here is a list of latest APKs for the distro http://dl-cdn.alpinelinux.org/alpine/latest-stable/main/x86_64/. Would it make sense to incorporate <ins>/depend on</ins> [abuild utility](https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers) in the targets, that will calculate the hashes and everything (for DRY)? This way, if they change the tool in future, we won't need to refactor.

claunia commented

2026-01-29 16:26:54 +00:00

@qmfrederik commented on GitHub (Jun 26, 2017):

@am11 Until now I've tried to implement everything in managed code (reusing existing .NET libraries where possible) to make sure you can run dotnet rpm,... on any operating system (e.g. I can run dotnet rpm -f netcoreapp1.1 -r rhel.7 on Windows and get a RPM package that I can use on Linux.

It looks like the file format is straightforward - two .tar.gz files; the data.tar.gz file being identical to what we use on Debian, and the control.tar.gz file seems to only contain text files. So there would at least be code reuse.

Just to set expectations - I'll probably do some work on the RPM format first, then move to Ubuntu/Debian and macOS next; PRs are always welcome :)

@qmfrederik commented on GitHub (Jun 26, 2017): @am11 Until now I've tried to implement everything in managed code (reusing existing .NET libraries where possible) to make sure you can run `dotnet rpm`,... on any operating system (e.g. I can run `dotnet rpm -f netcoreapp1.1 -r rhel.7` on Windows and get a RPM package that I can use on Linux. It looks like the file format is straightforward - two .tar.gz files; the `data.tar.gz` file being identical to what we use on Debian, and the `control.tar.gz` file seems to only contain text files. So there would at least be code reuse. Just to set expectations - I'll probably do some work on the RPM format first, then move to Ubuntu/Debian and macOS next; PRs are always welcome :)

claunia commented

2026-01-29 16:26:54 +00:00

@am11 commented on GitHub (Jun 26, 2017):

@qmfrederik, thanks. I agree doing everything in managed code is the way to go for xplat'ness. Just looked at the RPM implementation, I will try to chime in if I get something concrete ready for Alpine Linux. :)

@am11 commented on GitHub (Jun 26, 2017): @qmfrederik, thanks. I agree doing everything in managed code is the way to go for xplat'ness. Just looked at the RPM implementation, I will try to chime in if I get something concrete ready for Alpine Linux. :)

claunia referenced this issue

2026-01-29 16:30:54 +00:00

[PR #2] Alpha support for generating RPM packages #163

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dotnet-packaging#2