apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2023-12-19T12:23:07Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10819manage user and group creation/deletion directly2023-12-19T12:23:07ZAriadne Conillariadne@ariadne.spacemanage user and group creation/deletion directlyPresently, the majority of pre-install/post-install scripts in Alpine are doing user/group management. If apk did this instead, we could drop these scripts in the future.Presently, the majority of pre-install/post-install scripts in Alpine are doing user/group management. If apk did this instead, we could drop these scripts in the future.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10817licensing2022-12-21T19:32:49ZAriadne Conillariadne@ariadne.spacelicensingThere are a few minor licensing nitpicks we should clean up. As background, by far, the codebase was written by @fabled, with the majority of other contributions being @ncopa and myself, I think we have sufficient legal and moral author...There are a few minor licensing nitpicks we should clean up. As background, by far, the codebase was written by @fabled, with the majority of other contributions being @ncopa and myself, I think we have sufficient legal and moral authority to do these things, as well I think they are not really controversial.
## Lack of OpenSSL license exception
`apk-tools` is licensed as `GPL-2.0-only`. This means that even when Alpine switches to OpenSSL 3, this will not be sufficient, as the Apache license imposes additional restrictions (e.g. the software patents stuff) that are not in GPLv2. GPLv3 does add an exception allowing Apache-2 code to link to it, but the `GPL-2.0-only` license was chosen intentionally.
We can fix this by adding a license exception grant for OpenSSL. We may want to add a general exception for Apache 2.0 licensed programs as well.
## Makefile-based build system is `GPL-3.0-only`
This will likely be fixed by just removing the old build system once Muon is ready.
## `libapk` is `GPL-2.0-only`
It seems like we should relax the license on `libapk` to be LGPLv2.1. This would allow programs to link to `libapk` such as package management frontends, without worrying about the GPL, which seems ideal for encouraging further adoption of `libapk` and APK at large.
@fabled what do you think?v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10816Store package filename in database2024-03-25T15:53:51ZPaul SpoorenStore package filename in databaseCurrently the filename of packages is automatically generated based on the following structure:
```
<name>-<version>.apk
```
In OpenWrt, we currently use the structure below:
```
<name>_<version>-<arch>.ipk
```
We even use script for...Currently the filename of packages is automatically generated based on the following structure:
```
<name>-<version>.apk
```
In OpenWrt, we currently use the structure below:
```
<name>_<version>-<arch>.ipk
```
We even use script for cleaning up outdated packages that specifically look for the underscore (`<name>_`) in filenames.
I'm wondering if we could simply store the filename inside the index instead of enforcing a specific structure. For example, if I only provide a single package in multiple architectures, I could just fill a single folder with `<package>-<version>-<arch>.apk` instead of maintaining a variety of subfolders.
Thoughts?v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10813enhanced structured data for copyright tracking2022-12-21T19:37:22ZAriadne Conillariadne@ariadne.spaceenhanced structured data for copyright trackingAt work, we are writing a build-tool which generates APKv3 files as output. However, we would like to capture more of the copyright/license metadata than just the `license` field of `APKBUILD`.
I propose the following:
```
copyright:
...At work, we are writing a build-tool which generates APKv3 files as output. However, we would like to capture more of the copyright/license metadata than just the `license` field of `APKBUILD`.
I propose the following:
```
copyright:
- path: "[glob mask relevant to $srcdir]"
license: "[SPDX identifier, like old `license` field]"
attestations:
- "Copyright (c) 20XX foobar"
- "Copyright (c) 20XX baz"
```
An `APKBUILD` with `license="ISC"` would then map to:
```
copyright:
- path: "*"
license: "ISC"
```
If this seems agreeable, I can work on a patch next week for this. It is related to the SBOM work, see #10780.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10808Progress bar flushed by script execution2022-12-21T19:37:22ZPaul SpoorenProgress bar flushed by script executionIn OpenWrt every script executes a default `post-install` script which thereby always flushes the progress bar, it's only flickering around. Would it be possible to write the package installation progress bar after printing the execution...In OpenWrt every script executes a default `post-install` script which thereby always flushes the progress bar, it's only flickering around. Would it be possible to write the package installation progress bar after printing the execution message?
```
(15/139) Installing ucode-mod-uci (0_git20220126-r1)
Executing ucode-mod-uci_0_git20220126-r1.post-install
(16/139) Installing firewall4 (0_git20220128-r1)
Executing firewall4_0_git20220128-r1.post-install
(17/139) Installing ubi-utils (2.1.4-r1)
Executing ubi-utils_2.1.4-r1.post-install
(18/139) Installing fstools (0_git20211116-r2)
Executing fstools_0_git20211116-r2.post-install
(19/139) Installing getrandom (0_git20210803-r2)
Executing getrandom_0_git20210803-r2.post-install
(20/139) Installing hostapd-common (0_git20210522-r67)
Executing hostapd-common_0_git20210522-r67.post-install
...
```v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10805apk3: signing key generation applet2022-12-21T19:37:21ZDaniel Kolesaapk3: signing key generation appletWith the move to apk3, it will no longer be necessary to directly use `openssl` for signing, but apparently it is still necessary to use it to generate keys. Maybe apk should provide an applet to deal with that, to be able to drop direct...With the move to apk3, it will no longer be necessary to directly use `openssl` for signing, but apparently it is still necessary to use it to generate keys. Maybe apk should provide an applet to deal with that, to be able to drop direct `openssl` usage from tooling entirely?
Not entirely sure what the best interface to it would be. It probably does not have to be too user friendly, since its main purpose would be to be used from tooling (like `abuild` or others)v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10801Annoy the user when pinning packages from incompatible repositories2022-12-21T19:37:22ZAlex Xu (Hello71)Annoy the user when pinning packages from incompatible repositoriesMany users are following poorly-written tutorials and installing packages from incompatible repositories. For some non-Alpine distros, this may be allowed, but for Alpine it is not permitted to mix packages from different releases. There...Many users are following poorly-written tutorials and installing packages from incompatible repositories. For some non-Alpine distros, this may be allowed, but for Alpine it is not permitted to mix packages from different releases. There should be some mechanism for apk to tell the user that this is not supported. Two simple heuristics for Alpine would be checking the repository URL and the repository version, and if these don't match then raise an error. However, this may not work for third-party repositories or non-Alpine distros.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10798Support for package *alternatives*2024-03-11T18:03:48ZPaul SpoorenSupport for package *alternatives*Some packages offer *alternatives* meaning they offer the same binary binary path. An example would be that both `dropbear` and `openssh` offer `scp` to transfer files. Another is that `busybox` offers many packages from `coreutils`.
To...Some packages offer *alternatives* meaning they offer the same binary binary path. An example would be that both `dropbear` and `openssh` offer `scp` to transfer files. Another is that `busybox` offers many packages from `coreutils`.
To handle this some package managers offer handling of `alternatives`, which can be implemented in an array of triplets per package. Each triplet contain *priority*, *symlink path* and *package path*. Whenever a package is installed the *symlink paths* are compared and the *package path* with the highest *priority* is selected. A symlink is created which points the *symlink path* to the *package path*.
For example, the `dropbear` package may contain the triplet `100:/usr/bin/scp:usr/sbin/dropbear`, the `openssh` package may contain the triplet `200:/usr/bin/scp:/usr/libexec/scp-openss`. If both packages are installed, the one with highest priority (`openssh`) is symlinked.
This would be run whenever a package is installed or removed. The package manager OPKG implement the behaviour in a few [lines of code](https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/pkg_alternatives.c;h=24efedfd36576588467407b13bced862a73ad992;hb=refs/heads/master), maybe we can create something similar?v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10795Clarification on `passwd` field in adb file2022-12-21T19:37:21ZPaul SpoorenClarification on `passwd` field in adb fileLooking at [apk_adb.c](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/apk_adb.c#L508) I see a commented `passwd` entry. Is this supposed to allow the creation of `passwd` entries on a package basis?
I'm currently look...Looking at [apk_adb.c](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/apk_adb.c#L508) I see a commented `passwd` entry. Is this supposed to allow the creation of `passwd` entries on a package basis?
I'm currently looking for a solution to add users/groups during package installation. Currently this is solved by a custom post-install wrapper script, however a *in-APK* solution would be nicer.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10793apk search -e vim returns gvim2023-03-06T19:42:21ZBen Pageapk search -e vim returns gvim`apk search -e` seems to be broken in some cases. For `vim` rather than returning the exact match, the first partial match is returned.
```
> apk search -e vim
gvim-8.2.3650-r0
```
For reference:
```
> apk search -a -e vim
gvim-8.2.365...`apk search -e` seems to be broken in some cases. For `vim` rather than returning the exact match, the first partial match is returned.
```
> apk search -e vim
gvim-8.2.3650-r0
```
For reference:
```
> apk search -a -e vim
gvim-8.2.3650-r0
vim-8.2.3650-r0
```
```
> apk search -a vim
neovim-doc-0.5.1-r1
gvim-8.2.3650-r0
vim-8.2.3650-r0
vim-tutor-8.2.3650-r0
faenza-icon-theme-vim-1.3.1-r6
notmuch-vim-0.34-r0
kmymoney-5.1.2-r1
faenza-icon-theme-gvim-1.3.1-r6
meson-vim-0.59.3-r1
runvimtests-1.30-r1
graphviz-2.49.3-r0
neovim-0.5.1-r1
nftables-vim-0_git20200629-r1
vim-doc-8.2.3650-r0
vim-editorconfig-0.8.0-r0
apparmor-vim-3.0.3-r0
geany-plugins-vimode-1.38-r0
vimdiff-8.2.3650-r0
vimb-3.6.0-r0
neovim-lang-0.5.1-r1
u-boot-tools-2021.10-r5
fzf-neovim-0.28.0-r0
py3-pynvim-0.4.3-r2
nginx-vim-1.20.2-r0
msmtp-vim-1.8.19-r0
protobuf-vim-3.18.1-r1
vimb-doc-3.6.0-r0
icinga2-vim-2.13.1-r2
fzf-vim-0.28.0-r0
vim-sleuth-1.2-r0
gst-plugins-base-1.18.5-r0
mercurial-vim-5.9.3-r0apk
```
Funny enough this exact example is mentioned in the docs.
[https://docs.alpinelinux.org/user-handbook/0.1a/Working/apk.html](https://docs.alpinelinux.org/user-handbook/0.1a/Working/apk.html)v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10787Optional architecture adding to repository path2022-12-21T19:01:25ZPaul SpoorenOptional architecture adding to repository pathWhile Alpine repositories follow the structure `<feedname>/<arch>`, it's the other way around for OpenWrt. While this would be easy to switch on the OpenWrt side, we also have target specific packages which use unique path without the ar...While Alpine repositories follow the structure `<feedname>/<arch>`, it's the other way around for OpenWrt. While this would be easy to switch on the OpenWrt side, we also have target specific packages which use unique path without the architecture in it.
It would be useful to have the configuration option to disable *architecture addition* to repositories.
A workaround is to create a symlink like `ln -s . <arch>` but that's not ideal.
Example target specific repository:
* https://downloads.openwrt.org/snapshots/targets/x86/64/packages/
Example arch specific repository (feed *base*):
* https://downloads.openwrt.org/snapshots/packages/x86_64/base/v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10780support generation of an SBOM file describing the running system2022-12-21T19:37:22ZAriadne Conillariadne@ariadne.spacesupport generation of an SBOM file describing the running systemA frequent request I have gotten lately is that Alpine should support generating an SBOM file. An SBOM file is an emergent standard being pushed forward by the NTIA, which is designed to help auditors check for licensing compliance and ...A frequent request I have gotten lately is that Alpine should support generating an SBOM file. An SBOM file is an emergent standard being pushed forward by the NTIA, which is designed to help auditors check for licensing compliance and remediation compliance.
An SBOM file describes a system as a set of facts about each package (component), such as the package name, the hashes of every file belonging to it, the license and copyright declarations, the supplier (package maintainer), and any upstream contacts for the package. The NTIA have a report of [what they consider to be baseline](https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf).
Excluding the upstream contact information and copyright declarations, which really need to be done anyway for licensing compliance reasons, we already have all of the necessary information to construct a baseline SBOM.
The most common format for SBOMs is the SPDX format, I suggest we would want to implement this format.
The value to Alpine users should be obvious: we already have all the necessary information for them to generate this data, but right now, Alpine users needing to generate SBOMs have to use non-free software to do it.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10779apk3: mkpkg: support explicit ownership of files?2023-12-12T22:15:38ZDaniel Kolesaapk3: mkpkg: support explicit ownership of files?After investigating apk3 for my downstream distro use a bit, I came across one potential blocker. I need to be able to supply a way to set user/group ownership on certain files - currently I have my own generator for the packages, so I c...After investigating apk3 for my downstream distro use a bit, I came across one potential blocker. I need to be able to supply a way to set user/group ownership on certain files - currently I have my own generator for the packages, so I can do that just fine, but if creating packages becomes apk's responsibility, this is no longer going to be possible.
The reason for this is that in my case the builds run unprivileged in a sandbox that uses namespaces. This precludes creation of new users/groups (or rather, I can create them, but trying to use `chown` for any user/group other than the current primary will result in `EINVAL` - this makes sense because as an unprivileged user, the user within the namespace is mapped to your own user, and you can't really touch other uids and gids).
However, I don't really care about ownership of the files within the sandbox per se. All I care about is the ownership within the archive, since that's what will determine what user/group the files will be owned by. Would it be possible to add some kind of option to explicitly override ownerships on certain files, as well as ensure the ownership for everything else goes to root? (since things would be run with an unprivileged user effective uid/gid). Alternatively, maybe you have a better idea how to do this?
Thanksv3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10777Searching exact command name excludes matching results2023-10-12T10:08:44ZZach DeCookSearching exact command name excludes matching resultsI want to find a list of packages which provide `cmd:vis`.
If I do `apk search -q cmd:vis`, this provides
```
vis
outils-vis
calligra
sudo
```
Sudo is only shown because it provides `cmd:visudo` (calligra too), so I search with the `-...I want to find a list of packages which provide `cmd:vis`.
If I do `apk search -q cmd:vis`, this provides
```
vis
outils-vis
calligra
sudo
```
Sudo is only shown because it provides `cmd:visudo` (calligra too), so I search with the `--exact` flag.
```
outils-vis
```
`vis` seems to be missing because it provides more than just one cmd?
```sh
$ apk info -a vis
vis-0.7-r0 description:
Modern, legacy free, simple yet efficient vim-like editor
vis-0.7-r0 webpage:
https://github.com/martanne/vis
vis-0.7-r0 installed size:
1504 KiB
vis-0.7-r0 depends on:
!outils-vis
lua5.3-lpeg
so:libacl.so.1
so:libc.musl-aarch64.so.1
so:liblua-5.3.so.0
so:libncursesw.so.6
so:libtermkey.so.1
vis-0.7-r0 provides:
cmd:vis
cmd:vis-clipboard
cmd:vis-complete
cmd:vis-digraph
cmd:vis-menu
cmd:vis-open
vis-0.7-r0 has auto-install rule:
vis-0.7-r0 license:
ISC
```v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10776Show warning when http(s) repository returns (permanent) redirect2023-10-12T10:08:44ZKevin DaudtShow warning when http(s) repository returns (permanent) redirectFrom time to time, we need to decommission a mirror. In general, we redirect the DNS record to a different server and return a permanent redirect.
It would be nice if apk could show a warning that the mirror has been redirected so users...From time to time, we need to decommission a mirror. In general, we redirect the DNS record to a different server and return a permanent redirect.
It would be nice if apk could show a warning that the mirror has been redirected so users are aware and can adjust their `/etc/apk/repositories`.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10773apk bash-completion2022-12-21T19:39:44ZJ0WIapk bash-completionapk should ship it's own completion file. This makes it easier for both experienced and new users of Alpine to deal with software packages.apk should ship it's own completion file. This makes it easier for both experienced and new users of Alpine to deal with software packages.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10771pkgusers/pkggroups + install -o/-g doesn't stick in /var2023-12-12T22:22:03ZDrew DeVaultpkgusers/pkggroups + install -o/-g doesn't stick in /varhttps://git.sr.ht/~sircmpwn/sr.ht-apkbuilds/tree/master/item/sr.ht/sr.ht-uacme/APKBUILD#L43
This does not seem to work; I have to add a post-install to force the desired user/group. The tarball looks right, though, may be an apk-tools i...https://git.sr.ht/~sircmpwn/sr.ht-apkbuilds/tree/master/item/sr.ht/sr.ht-uacme/APKBUILD#L43
This does not seem to work; I have to add a post-install to force the desired user/group. The tarball looks right, though, may be an apk-tools issue?v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10769[RFC] rename apk to avoid confusion with Android package format2022-12-21T19:39:44ZPaul Spooren[RFC] rename apk to avoid confusion with Android package formatWhenever looking up issues or code around the `apk` package manage I'll likely find results describing corner cases of the Android package format `.apk`.
I'm wondering if a *better* name could be found in some future. Clearly this is no...Whenever looking up issues or code around the `apk` package manage I'll likely find results describing corner cases of the Android package format `.apk`.
I'm wondering if a *better* name could be found in some future. Clearly this is not a pushing issues but I'm a bit concerned that once `apk` is used for *OpenWrt*, a flood of obscure error messages and confused user appear.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10765Add support for variables in /etc/apk/repositories like Yum has2022-12-21T19:39:44ZChristoph ObexerAdd support for variables in /etc/apk/repositories like Yum hasThis would IMO solve #10756 by replacing the repo in /etc/apk/repositories by a caching proxy
An example need of such a feature is documented in the wiki:
https://wiki.alpinelinux.org/wiki/Alpine_newbie_apk_packages#New_users:_installin...This would IMO solve #10756 by replacing the repo in /etc/apk/repositories by a caching proxy
An example need of such a feature is documented in the wiki:
https://wiki.alpinelinux.org/wiki/Alpine_newbie_apk_packages#New_users:_installing_needed_packages
```
# old /etc/apk/repositories from the example above
cat > /etc/apk/repositories << EOF; $(echo)
http://dl-cdn.alpinelinux.org/alpine/v$(cat /etc/alpine-release | cut -d'.' -f1,2)/main
EOF
```
would become:
```
# proposed /etc/apk/repositories
cat > /etc/apk/repositories << EOF; $(echo)
http://dl-cdn.alpinelinux.org/alpine/v\$releasever/main
EOF
```
Now that is of little use, BUT we use Artifactory as cache and thus point our Alpine containers to a repo mirror there... but need a separate repo file for every alpine release or synthesize a repo file based on the alpine release... that sounds easy enough but the code that needs to synthesize the repo file needs to be running outside the container and thus has to guess the correct release number from docker tags for various base images (node, go, java, ...)...
We would love to be able to just bind mount `/etc/apk/repositories` with our artifactory repositories (and credentials) without fancy magic and use `$releasever` as a placeholder for the version inside them.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10761Proposal: Make apk-fetch respect --arch too2024-03-25T11:49:10ZSören TempelProposal: Make apk-fetch respect --arch tooThe `--arch` flag is a global option to `apk(8)`. Unfortunately, it only seems to be respected presently when used in conjunction with `--root`. For this reason, `apk fetch --arch riscv64 linux-edge` will download the `linux-edge` packag...The `--arch` flag is a global option to `apk(8)`. Unfortunately, it only seems to be respected presently when used in conjunction with `--root`. For this reason, `apk fetch --arch riscv64 linux-edge` will download the `linux-edge` package for the host architecture (e.g. `x86_64`, not for `riscv64`). Unfortunately, it also does not emit an error message which is very confusing.
I would propose the following changes:
1. Make `apk-fetch(8)` respect `--arch`, e.g. `apk fetch --arch riscv64 linux-edge` should download the `linux-edge` package for the `riscv64` architecture.
2. Make `apk` subcommands which do not support `--arch` fail. This was a source of confusion in the past, see for example https://gitlab.alpinelinux.org/alpine/aports/-/issues/12905v3.1