apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2023-03-06T19:42:21Zhttps://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/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/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.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10754apk should prune obsolete indices2023-04-10T20:13:17ZAriadne Conillariadne@ariadne.spaceapk should prune obsolete indicesOn my machine:
```
treefort:~$ ls -al /var/cache/apk/APKINDEX.*
-rw-r--r-- 1 root root 656814 Sep 22 2020 /var/cache/apk/APKINDEX.066df28d.tar.gz
-rw-r--r-- 1 root root 634253 Sep 6 2020 /var/cache/apk/APK...On my machine:
```
treefort:~$ ls -al /var/cache/apk/APKINDEX.*
-rw-r--r-- 1 root root 656814 Sep 22 2020 /var/cache/apk/APKINDEX.066df28d.tar.gz
-rw-r--r-- 1 root root 634253 Sep 6 2020 /var/cache/apk/APKINDEX.2c4ac24e.tar.gz
-rw-r--r-- 1 root root 633808 Sep 22 2020 /var/cache/apk/APKINDEX.30e6f5af.tar.gz
-rw-r--r-- 1 root root 1145983 Sep 6 2020 /var/cache/apk/APKINDEX.40a3604f.tar.gz
-rw-r--r-- 1 root root 1566651 Jun 25 13:03 /var/cache/apk/APKINDEX.74fbe57d.tar.gz
-rw-r--r-- 1 root root 642689 Jun 25 13:03 /var/cache/apk/APKINDEX.924f3f67.tar.gz
-rw-r--r-- 1 root root 1226681 Sep 22 2020 /var/cache/apk/APKINDEX.b53994b4.tar.gz
-rw-r--r-- 1 root root 638355 Jun 25 13:03 /var/cache/apk/APKINDEX.e3b89664.tar.gz
```
@mps has also noticed similar. We should garbage collect these obsolete indices.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10726`apk update/upgrade --no-cache` exits with exitstatus 0, where it uses 2 with...2022-12-28T12:59:45ZDaniel Hahler`apk update/upgrade --no-cache` exits with exitstatus 0, where it uses 2 without `--no-cache``apk update` exits with status 2 if it fails to download files, but when using `--no-cache` it does not.
This might be ok given that the cache is not updated, but also affects `apk upgrade`, where it certainly should be a failure from w...`apk update` exits with status 2 if it fails to download files, but when using `--no-cache` it does not.
This might be ok given that the cache is not updated, but also affects `apk upgrade`, where it certainly should be a failure from what I can see.
```
% docker run -it --rm alpine
/ # apk update; echo $?
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.12/main: temporary error (try again later)
WARNING: Ignoring APKINDEX.2c4ac24e.tar.gz: No such file or directory
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.12/community: temporary error (try again later)
WARNING: Ignoring APKINDEX.40a3604f.tar.gz: No such file or directory
2 errors; 14 distinct packages available
2
/ # apk update --no-cache; echo $?
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz: temporary error (try again later)
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz: temporary error (try again later)
OK: 14 distinct packages available
0
/ # apk --version
apk-tools 2.10.5, compiled for x86_64.
/ # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.12.1
PRETTY_NAME="Alpine Linux v3.12"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
```
Using `alpine:latest` Docker image (d6e46aa2470d).v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10717apk version: missing options in help output2022-12-28T09:18:25ZKevin Daudtapk version: missing options in help outputVersion 2.12.0, `apk version -h` is missing these options:
```
-I, --indexes Print description and versions of indexes
-t, --test Compare two given versions, output '<', '=' or '>'
-c, --check Ch...Version 2.12.0, `apk version -h` is missing these options:
```
-I, --indexes Print description and versions of indexes
-t, --test Compare two given versions, output '<', '=' or '>'
-c, --check Check the given version strings, output any that are invalid
```
They seem to still work, just not documented.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10670Package signatures should not use SHA-12022-12-22T12:32:16ZReid RankinPackage signatures should not use SHA-1While investigating the APK format, I've realized that the signatures on packages are still done using SHA-1. This is odd, because the signature is over control.tar.gz -- which is bound to data.tar.gz using a SHA-256 hash. In any case, n...While investigating the APK format, I've realized that the signatures on packages are still done using SHA-1. This is odd, because the signature is over control.tar.gz -- which is bound to data.tar.gz using a SHA-256 hash. In any case, now that relatively inexpensive SHA-1 preimage attacks are publically known, we should move to eliminate the use of SHA-1 quickly.
While apk-tools/src/package.c seems to indicate some support for checking "RSA256" signatures, abuild will never make them, and I'm suspicious of apk_sign_ctx_init's seemingly exclusive use of SHA-1. And while we're at it, the APK-TOOLS.checksum.SHA1 tar attribute should probably be replaced (or augmented) with a SHA256 version. (Pretty sure this is just a change at abuild/abuild-tar:383)v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10663Remove the need for gzip apk2024-02-19T15:53:42ZFredrik GustafssonRemove the need for gzip apkToday and apk package is built by data.tar.gz, control.tar.gz and signature.tar.gz. Sometime (when using apk in yocto) the speed of build is more important than the size of the packages. Therefore it should be possible to create apk-pack...Today and apk package is built by data.tar.gz, control.tar.gz and signature.tar.gz. Sometime (when using apk in yocto) the speed of build is more important than the size of the packages. Therefore it should be possible to create apk-packages with only data.tar, control.tar and signature.tar. That is no compression. apk should have support for installing apk packages with different compression (including no compression).v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10533Support "epoch" in APKBUILD, like it works in PKGBUILD2024-03-14T14:25:39ZOliver SmithSupport "epoch" in APKBUILD, like it works in PKGBUILDSometimes software needs to follow a new versioning scheme, which would
make newer releases appear to have a smaller version than older
releases.
Arch Linux has the “epoch” field in their PKGBUILDs:
https://wiki.archlinux.org/index.ph...Sometimes software needs to follow a new versioning scheme, which would
make newer releases appear to have a smaller version than older
releases.
Arch Linux has the “epoch” field in their PKGBUILDs:
https://wiki.archlinux.org/index.php/PKGBUILD#epoch
It would be nice to have this in Alpine too (abuild is makepkg light
after all ;)).
(This does not have any priority to me right now, otherwise I would work
towards implementing this in apk-tools, if it is desired.)
*(from redmine: issue id 10533, created on 2019-06-01)*backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7103Add ability for apk to extract files, extended headers, and metadata directly...2022-12-21T18:49:35ZChris GiorgiAdd ability for apk to extract files, extended headers, and metadata directly from .apksCurrently, apk offers no direct way to extract specific contents or
metadata from .apks files and the pax headers utilized in the .apk
archive format are not easily read with any available tool.
Many scripts need to extract a subset of ...Currently, apk offers no direct way to extract specific contents or
metadata from .apks files and the pax headers utilized in the .apk
archive format are not easily read with any available tool.
Many scripts need to extract a subset of files from a .apk, and the
current method requires either downloading to a temp directory or using
apk fetch to stdout pipe repeatedly (which is very wasteful for multiple
invocations), verifying with ‘apk verify’, listing with ‘tar -tvf’ piped
to sed (using a subshell to generate the expressions) looking for the
desired files, capturing which of the desired files are found in the
.apk, and finally extracting the found files using ‘tar -xvf’.
Additionally, none of the available tools can read the pax headers in a
usable form, reducing one to parsing the raw tar stream with awk to
extract the desired headers and metadata, such as checksums.
apk should expose functionality allowing extracting or retrieving all
information from each entry as well as accessing archive-level
meta-data, and should support basic fnmatch style globbing of entries to
be extracted.
*(from redmine: issue id 7103, created on 2017-04-08)*v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5369Add support for LZ42024-02-19T15:48:48ZCarlo LandmeterAdd support for LZ4According to the author on: https://github.com/Cyan4973/lz4 lz4
decompresses almost by a factor 7 compared to zlib while keeping
compression at similar level.
Would this be an possible candidate to replace zlib in apk?
*(from redmine...According to the author on: https://github.com/Cyan4973/lz4 lz4
decompresses almost by a factor 7 compared to zlib while keeping
compression at similar level.
Would this be an possible candidate to replace zlib in apk?
*(from redmine: issue id 5369, created on 2016-04-05)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5073Priority for directory permissions2024-03-19T12:58:43ZKaarle RitvanenPriority for directory permissionsCurrently, apk uses a specific algorithm to combine the directory mode
and owner information from all installed packages. In some cases,
rendering the desired permissions in the file system requires adjusting
the APKBUILD file of all pac...Currently, apk uses a specific algorithm to combine the directory mode
and owner information from all installed packages. In some cases,
rendering the desired permissions in the file system requires adjusting
the APKBUILD file of all packages containing the directory.
The suggested solution is to allow setting a directory permission
priority on per package basis. This attribute would control which
package takes precedence in determining the permissions, similar to how
‘replaces\_priority’ affects file permissions and content. If the
highest priority would be claimed by multiple packages, apk would revert
to the current behavior, taking only the highest-priority packages into
account.
*(from redmine: issue id 5073, created on 2016-02-04)*v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10986xattrs are not correctly treated by audit2024-03-26T13:09:53ZDaniel Kolesaxattrs are not correctly treated by auditWhen you have binaries with xattrs, they will always show as `x` in audit:
```
x usr/bin/clockdiff
x usr/bin/ping
```
the binaries otherwise have correct permissions/xattrsWhen you have binaries with xattrs, they will always show as `x` in audit:
```
x usr/bin/clockdiff
x usr/bin/ping
```
the binaries otherwise have correct permissions/xattrshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10984meson: openssl_static dependency in libfetch results in double linking2024-03-21T12:07:36ZDaniel Kolesameson: openssl_static dependency in libfetch results in double linkingThe recent changes brought in a libfetch dependency on openssl, however this results in openssl for now harmlessly being linked twice. Worse would be if it tried to link the second openssl statically, which it does not for now. Either wa...The recent changes brought in a libfetch dependency on openssl, however this results in openssl for now harmlessly being linked twice. Worse would be if it tried to link the second openssl statically, which it does not for now. Either way, it should only link once.
potential patch:
```
From 58feb1d66f8ec5e1f607dabd8c83ae725c3dc1ac Mon Sep 17 00:00:00 2001
From: q66 <q66@chimera-linux.org>
Date: Thu, 21 Mar 2024 12:04:58 +0100
Subject: [PATCH] libfetch: fix openssl dependency specification
We shouldn't include the full static linkage as it may accidentally
bring static openssl into the apk link path. We only care about the
includes here, so do that.
---
libfetch/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libfetch/meson.build b/libfetch/meson.build
index 7406fbb..59ea789 100644
--- a/libfetch/meson.build
+++ b/libfetch/meson.build
@@ -38,7 +38,7 @@ libfetch = static_library(
'fetch',
libfetch_src,
c_args: libfetch_cargs,
- dependencies: openssl_static_dep,
+ dependencies: openssl_dep.partial_dependency(compile_args: true, includes: true),
)
libfetch_dep = declare_dependency(
--
2.44.0
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10983can no longer extract packages as user since --usermode changes2024-03-21T12:36:12ZDaniel Kolesacan no longer extract packages as user since --usermode changesThe usermode changes were made for apk add, but do not account for manual package extraction.The usermode changes were made for apk add, but do not account for manual package extraction.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10982apk3: conflicts are broken since recently2024-03-20T18:37:56ZDaniel Kolesaapk3: conflicts are broken since recentlySome of the recent changes broke package conflicts. Instead, the `!` is stripped and it's considered a dependency. The actual package metadata in adb is still correct.Some of the recent changes broke package conflicts. Instead, the `!` is stripped and it's considered a dependency. The actual package metadata in adb is still correct.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10981apk3: running triggers now always leaves apk in error state2024-03-20T13:40:45ZDaniel Kolesaapk3: running triggers now always leaves apk in error state```
root@cbuild: ~$ apk fix base-shells
The following packages will be reinstalled:
base-shells
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Reinstalling base-shells (0.1-r0)
E...```
root@cbuild: ~$ apk fix base-shells
The following packages will be reinstalled:
base-shells
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Reinstalling base-shells (0.1-r0)
Executing base-shells-0.1-r0.trigger
Regenerating /etc/shells...
1 error; 1286 MiB in 145 packages
root@cbuild: ~$ apk fix
After this operation, 0 B of additional disk space will be used.
OK: 1286 MiB in 145 packages
root@cbuild: ~$ apk fix base-shells
The following packages will be reinstalled:
base-shells
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Reinstalling base-shells (0.1-r0)
Executing base-shells-0.1-r0.trigger
Regenerating /etc/shells...
1 error; 1286 MiB in 145 packages
```
Relevant commit is probably 60fec0bd3de1c3f8f6747fbc170765c69e0de438https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10980apk3: segfaults since recent updates2024-03-20T15:06:42ZDaniel Kolesaapk3: segfaults since recent updatesTried to update in Chimera from c8c9df1825760e558f44397500af2a2f4bca18d4 to latest master.
Immediately encountered a segfault:
```
root@cbuild: ~$ apk add perl
The following NEW packages will be installed:
less perl
After this operat...Tried to update in Chimera from c8c9df1825760e558f44397500af2a2f4bca18d4 to latest master.
Immediately encountered a segfault:
```
root@cbuild: ~$ apk add perl
The following NEW packages will be installed:
less perl
After this operation, 51 MiB of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/2) Installing less (643-r0)
(2/2) Installing perl (5.38.2-r0)
8% ███████████████ Segmentation fault (core dumped)
root@cbuild: ~$ lldb -c core.12
(lldb) target create --core "core.12"
Core file '/tmp/core.12' (x86_64) was loaded.sl-x86_64.so.1...
(lldb) bt
* thread #1, name = 'apk', stop reason = signal SIGSEGV: address not mapped to object
* frame #0: 0x00007c4e64fcbce1 libapk.so.2`apk_db_dir_prepare(db=0x000059597e8d3830, dir=0x00007c4e644c5c70) at database.c:276:20
frame #1: 0x00007c4e64fd949f libapk.so.2`apk_db_install_file(ectx=0x00007ffec51c63a0, ae=0x00007ffec51c3de8, is=0x0000000000000000) at database.c:2757:3
frame #2: 0x00007c4e64fdb5b4 libapk.so.2`apk_extract_v3_next_file [inlined] apk_extract_v3_directory(ectx=0x00007ffec51c63a0) at extract_v3.c:128:6
frame #3: 0x00007c4e64fdb3dc libapk.so.2`apk_extract_v3_next_file(ectx=0x00007ffec51c63a0) at extract_v3.c:164:8
frame #4: 0x00007c4e64fdb196 libapk.so.2`apk_extract_v3_data_block(db=0x00007ffec51c4088, b=<unavailable>, is=0x00007ffec51c3f60) at extract_v3.c:192:6
frame #5: 0x00007c4e64fbd630 libapk.so.2`adb_m_process at adb.c:244:7
frame #6: 0x00007c4e64fbd22c libapk.so.2`adb_m_process(db=0x00007ffec51c4088, is=0x00007c4e64832f30, expected_schema=<unavailable>, t=0x000059597e8d35b8, cb=<unavailable>) at adb.c:280:9
frame #7: 0x00007c4e64fdaf1d libapk.so.2`apk_extract_v3(ectx=0x00007ffec51c63a0, is=0x00007c4e64f04fc0) at extract_v3.c:253:6
frame #8: 0x00007c4e64fd4fe2 libapk.so.2`apk_db_install_pkg [inlined] apk_extract(ectx=<unavailable>, is=0x00007c4e64f04fc0) at extract_v3.c:292:41
frame #9: 0x00007c4e64fd4fdd libapk.so.2`apk_db_install_pkg [inlined] apk_db_unpack_pkg(db=0x000059597e8d3830, ipkg=0x00007c4e62fd2010, upgrade=<unavailable>, cb=(libapk.so.2`progress_cb at commit.c:129:37), cb_ctx=0x00007ffec51c64c0, script_args=0x00007ffec51c5240) at database.c:2996:6
frame #10: 0x00007c4e64fd4e21 libapk.so.2`apk_db_install_pkg(db=0x000059597e8d3830, oldpkg=0x0000000000000000, newpkg=0x00007c4e6399e610, cb=(libapk.so.2`progress_cb at commit.c:129:37), cb_ctx=0x00007ffec51c64c0) at database.c:3047:7
frame #11: 0x00007c4e64fc880a libapk.so.2`apk_solver_commit_changeset(db=0x000059597e8d3830, changeset=0x00007ffec51c65a0, world=0x00007c4e62a77a40) at commit.c:377:9
frame #12: 0x00007c4e64fca62e libapk.so.2`apk_solver_commit(db=0x000059597e8d3830, solver_flags=0, world=0x00007c4e62a77a40) at commit.c:813:7
frame #13: 0x000059597e861359 apk`add_main(ctx=0x00007c4e651039f0, ac=<unavailable>, args=0x00007c4e65163e50) at app_add.c:209:6
frame #14: 0x000059597e86073a apk`main(argc=1, argv=0x00007ffec51c7348) at apk.c:616:6
frame #15: 0x00007c4e65457bca ld-musl-x86_64.so.1`libc_start_main_stage2(main=(apk`main at apk.c:493), argc=<unavailable>, argv=0x00007ffec51c7338) at __libc_start_main.c:95:7
frame #16: 0x000059597e85fa76 apk`_start + 22
(lldb) p dir->owner
(apk_db_dir_instance *) NULL
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10979make zstd dependency optional2024-03-16T13:15:07ZPaul Spoorenmake zstd dependency optionalWould be nice to have zstd support as a meson option, Ideally we don't force OpenWrt to include libzstd by default.Would be nice to have zstd support as a meson option, Ideally we don't force OpenWrt to include libzstd by default.