alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2022-12-21T18:49:35Zhttps://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/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/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/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/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/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/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/10826apk3: provider_priority deprecated?2023-10-12T10:08:44ZDaniel Kolesaapk3: provider_priority deprecated?I see in the mapping code that the priority field for adb maps to replaces_priority, and provider_priority does not seem to be read anymore? Is it deprecated? If so, how is one supposed to replace it?I see in the mapping code that the priority field for adb maps to replaces_priority, and provider_priority does not seem to be read anymore? Is it deprecated? If so, how is one supposed to replace it?v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10830Support OPKG/Debian version compare algorithm2024-03-14T14:15:17ZPaul SpoorenSupport OPKG/Debian version compare algorithmHi, while OpenWrt is overall excited moving to APK, a big blocker is the entirely different structure of versions. I already created dozens of patches to build just the base system, however much more is required to get things working. Ev...Hi, while OpenWrt is overall excited moving to APK, a big blocker is the entirely different structure of versions. I already created dozens of patches to build just the base system, however much more is required to get things working. Even more so since people want hashes in their versions which is currently impossible with APK.
A more generic approach would be to use the rather simple algorithm from OPKG/Debian to compare package versions and choose the latest one, a simple implementation is available [here](https://github.com/openwrt/packages/blob/master/utils/auc/src/auc.c#L367).
Could we add this side by side with the current version comparing algorithm?
CC: @ariadnev3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10837apk3: wrong ACLs applied when initializing new system2023-02-16T18:56:06ZDaniel Kolesaapk3: wrong ACLs applied when initializing new systemexample:
```
q66@rimi: /home/q66/cports-orig$ sudo mkdir test
q66@rimi: /home/q66/cports-orig$ sudo apk --root test --repository /home/q66/cports-orig/packages/main --keys-dir /home/q66/cports-orig/etc/keys --initdb add base-files
(1/...example:
```
q66@rimi: /home/q66/cports-orig$ sudo mkdir test
q66@rimi: /home/q66/cports-orig$ sudo apk --root test --repository /home/q66/cports-orig/packages/main --keys-dir /home/q66/cports-orig/etc/keys --initdb add base-files
(1/1) Installing base-files (0.1-r0)
OK: 0 MiB in 1 packages
q66@rimi: /home/q66/cports-orig$ ls -l test
total 56
lrwxrwxrwx 1 65534 65534 7 Apr 15 02:39 bin -> usr/bin
drwxr-xr-x 2 65534 65534 4096 Apr 15 02:39 boot
drwxr-xr-x 2 65534 65534 4096 Apr 15 02:39 dev
drwxr-xr-x 6 65534 65534 4096 Apr 15 02:39 etc
drwxr-xr-x 2 65534 65534 4096 Apr 15 02:39 home
lrwxrwxrwx 1 65534 65534 7 Apr 15 02:39 lib -> usr/lib
drwxr-xr-x 2 65534 65534 4096 Apr 15 02:39 media
drwxr-xr-x 2 65534 65534 4096 Apr 15 02:39 mnt
drwxr-xr-x 2 65534 65534 4096 Apr 15 02:39 opt
dr-xr-xr-x 2 root root 4096 Apr 15 02:39 proc
drwxr-x--- 2 65534 65534 4096 Apr 15 02:39 root
drwxr-xr-x 3 65534 65534 4096 Apr 15 02:39 run
lrwxrwxrwx 1 65534 65534 7 Apr 15 02:39 sbin -> usr/bin
drwxr-xr-x 2 65534 65534 4096 Apr 15 02:39 sys
drwxrwxrwx 2 65534 65534 4096 Apr 15 02:39 tmp
drwxr-xr-x 8 65534 65534 4096 Apr 15 02:39 usr
drwxr-xr-x 10 root root 4096 Apr 15 02:39 var
```
The `base-files` in my case is the first package that gets installed, containing `/etc/passwd` and `/etc/group` besides other things. However, the idcache does not account for it, and gives all these files the fallback owner. When installing a larger metapackage (like `base-minimal` that installs `base-files` first, most of the installed files still have wrong ownership. Only from certain point onwards (when scriptlets are first run) do the files have correct owner/group.
A quick solution for this would be to make `root` special, and always pre-populate that in the idcache (by the time more users are added, the `passwd` should be readable) but maybe you have a better solution in mind?v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10840Segmentation fault in on_sigint2022-12-22T13:14:48ZDominika LiberdaSegmentation fault in on_sigintSteps to reproduce:
1. run `apk add`
2. pass SIGINT (well, ctrl+c) right after it prints the package db info, but before it quits. Takes a few tries, but I can quite reliably trigger it now.
3. it segfaults
For triggering it in GDB, yo...Steps to reproduce:
1. run `apk add`
2. pass SIGINT (well, ctrl+c) right after it prints the package db info, but before it quits. Takes a few tries, but I can quite reliably trigger it now.
3. it segfaults
For triggering it in GDB, you additionally need to pass `handle SIGINT noprint nostop pass`, because we don't want a break on SIGINT.
Backtrace:
```
#0 0x00007ffff7f8a933 in ?? () from /lib/ld-musl-x86_64.so.1
#1 0x00007ffff7f8acab in ?? () from /lib/ld-musl-x86_64.so.1
#2 0x00007ffff7f9d5cd in munmap () from /lib/ld-musl-x86_64.so.1
#3 0x0000555555566198 in db ()
#4 0x0000555555565880 in ?? ()
#5 0x0000000000000001 in ?? ()
#6 0x0000000000000030 in ?? ()
#7 0x00005555555661f8 in db ()
#8 0x00007ffff7cc67a0 in ?? () from /lib/libapk.so.3.12.0
#9 0x00007ffff782a210 in ?? ()
#10 0x00007ffff7ca739c in apk_db_close (db=0x555555565880 <db>) at src/database.c:1830
#11 0x0000555555558fc4 in on_sigint (s=2) at src/apk.c:424
#12 <signal handler called>
#13 0x00007ffff7f9d5cd in munmap () from /lib/ld-musl-x86_64.so.1
#14 0x00007ffff7ffdb7c in ?? () from /lib/ld-musl-x86_64.so.1
#15 0x0000000000002000 in ?? ()
#16 0x00007ffff7f8ae2a in ?? () from /lib/ld-musl-x86_64.so.1
#17 0x000000040000007f in ?? ()
#18 0x00007ffff7f8accc in ?? () from /lib/ld-musl-x86_64.so.1
#19 0x0000001d7fffffff in ?? ()
#20 0x00007ffff6b470a8 in ?? ()
#21 0x00007ffff6b47090 in ?? ()
#22 0x00005555555661c8 in db ()
#23 0x0000000000000000 in ?? ()
```v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10848Ignore empty package names2024-02-14T15:36:58ZMarcin KielarIgnore empty package names# Context
We use a sh/bash _trick_ to embed inline comments when we upgrade packages to fix vulnerabilities in our Docker Images. The _trick_ looks like this:
```dockerfile
RUN ... some commands ... \
&& apk add --no-cache --upgrade...# Context
We use a sh/bash _trick_ to embed inline comments when we upgrade packages to fix vulnerabilities in our Docker Images. The _trick_ looks like this:
```dockerfile
RUN ... some commands ... \
&& apk add --no-cache --upgrade \
some-package "$(: 'Fixes CVE-1234')" \
&& ...some more commands...
```
This keeps our Docker Image nice and tidy (just one layer to install all dependencies). We use that with `yum` and `apt-get`, as we have images build from AmazonLinux2 and Ubuntu, and the trick works nicely there.
We also have images built from Alpine, though, which is where the _trick_ doesnt work.
# Example
Consider following `Dockerfile`:
```dockerfile
FROM mcr.microsoft.com/dotnet/sdk:5.0-alpine AS base-build
#hadolint ignore=DL3013,DL3018
RUN apk add --no-cache \
jq \
curl \
python3 \
py3-pip \
&& apk add --no-cache --upgrade \
pcre2>10.40-r0 "$(: 'Fixes https://security.snyk.io/vuln/SNYK-ALPINE315-PCRE2-2869384')" \
&& pip3 install --no-cache-dir --upgrade \
pip \
&& pip3 install --no-cache-dir \
awscli \
&& rm -rf /var/cache/apk/*
```
When building this, the `apk add --no-cache --upgrade pcre2...` command fails. This is because `apk` is given two strings which it interprets as package names:
- the `"pcre2>10.40-r0"` which properly identifies what we want to install
- the `""` which is a result of the _inline comment trick_ we use.
The error message is:
```
#5 1.223 ERROR: unable to select packages:
#5 1.273 (no such package):
#5 1.273 required by: world[]
```
# Feature request
Make `apk` ignore empty-string package names. This way it will work the same way as `apt-get` and `yum`.
# Existing workarounds
Removing the double quotes from the _inline comment trick_ works:
```dockerfile
RUN ... some commands ... \
&& apk add --no-cache --upgrade \
some-package $(: 'Fixes CVE-1234') \
&& ...some more commands...
```
However, this additionally triggers a `hadolint` warning:
```
Dockerfile:4 SC2046 warning: Quote this to prevent word splitting.
```
We can add an ignore for the warning, but we'd much rather have `apk` just ignore empty strings.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10854apk3: making --no-chown more useful?2022-12-22T14:13:42ZDaniel Kolesaapk3: making --no-chown more useful?In my build system, I thought I could possibly use `--no-chown` to be able to use `apk add` to create a root filesystem for a user namespace without needing `fakeroot` (in the namespace I don't really care about ownership since it's unpr...In my build system, I thought I could possibly use `--no-chown` to be able to use `apk add` to create a root filesystem for a user namespace without needing `fakeroot` (in the namespace I don't really care about ownership since it's unprivileged and restricted to a single UID). However, this does not seem to work, because while `--no-chown` will indeed prevent the `fchownat` calls from taking place, I am still getting `EPERM` during `renameat` in the commit step.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10855apk3: adb can't handle more than 8000 files per directory2023-09-18T07:35:48ZDaniel Kolesaapk3: adb can't handle more than 8000 files per directoryI have run into this bottleneck today (the `include/config` directory in Linux kernel development headers). Trying to create a package with more than 8000 files per directory will trigger an assertion failure (or an adb header failure at...I have run into this bottleneck today (the `include/config` directory in Linux kernel development headers). Trying to create a package with more than 8000 files per directory will trigger an assertion failure (or an adb header failure at a later point if apk is compiled with assertions off) through `adb_wa_append_obj` (because `.num_fields` is initialized to `APK_MAX_MANIFEST_FILES`, which is 8000).v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10857`apk cache clean` doesn't remove package downloads in /var/cache/apk/2023-10-12T10:08:43ZEllie`apk cache clean` doesn't remove package downloads in /var/cache/apk/`apk cache clean` doesn't remove package downloads in /var/cache/apk/ with apk 2.12.9 as found on postmarketOS 22.06. I think it would be highly expected that it does, so I suggest that it is changed to do so. This is especially irritati...`apk cache clean` doesn't remove package downloads in /var/cache/apk/ with apk 2.12.9 as found on postmarketOS 22.06. I think it would be highly expected that it does, so I suggest that it is changed to do so. This is especially irritating with apk getting stuck on a corrupted download, somehow not being smart enough to do anything about it even on retrying install, and then `apk cache clean` just does nothing of use. Very confusing!v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10859apk3: handle xattrs2023-10-15T16:38:22ZDaniel Kolesaapk3: handle xattrsIt seems adb does not handle those at all yet (even though the other layers support them).It seems adb does not handle those at all yet (even though the other layers support them).v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10864apk-tool sort results of search2023-10-12T10:08:44ZJustinapk-tool sort results of searchapk search does not sort results in alphabetical order, user must either scour the list or pipe it to sort.apk search does not sort results in alphabetical order, user must either scour the list or pipe it to sort.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10866Sort upgrade package list2023-02-14T13:05:31ZJustinSort upgrade package list```
The following packages will be upgraded:
cryptsetup-libs cryptsetup cryptsetup-openrc llvm15-libs libpng abuild tzdata wavpack appstream appstream-qt discover discover-backend-apk libpng-dev discover-lang appstream-lang clang15-lib...```
The following packages will be upgraded:
cryptsetup-libs cryptsetup cryptsetup-openrc llvm15-libs libpng abuild tzdata wavpack appstream appstream-qt discover discover-backend-apk libpng-dev discover-lang appstream-lang clang15-libclang kpipewire kpipewire-lang plasma-pa plasma-pa-lang
```
This is not that nice to try read if you're looking to see if a specific package has an upgrade available.
A sorted list would be better like
```
abuild
appstream
appstream-lang
appstream-qt
clang15-libclang
cryptsetup
cryptsetup-libs
cryptsetup-openrc
discover
discover-backend-apk
discover-lang
kpipewire
kpipewire-lang
libpng
libpng-dev
llvm15-libs
plasma-pa
plasma-pa-lang
tzdata
wavpack
```v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10869Support for faster TCP/HTTP timeout on stale network2023-10-12T14:50:17ZCarlo DéSupport for faster TCP/HTTP timeout on stale networkHello,
It seems apk update, at least on alpine 3.16, has no timeout at all. When the targeted mirror is down, it just keeps trying to get the APKINDEX.tar.gz forever.
The man-page says the command has no option. If it is not feasible t...Hello,
It seems apk update, at least on alpine 3.16, has no timeout at all. When the targeted mirror is down, it just keeps trying to get the APKINDEX.tar.gz forever.
The man-page says the command has no option. If it is not feasible to add a "--timeout" option, would it be at least possible to set a decent internal timeout (< 5min)? As is, when the system's automatically upgraded during the boot, you end with a de facto frozen box.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10879APK prints warnings and errors to STDOUT not STDERR (re-opened)2023-03-03T11:02:01ZMartin BraunAPK prints warnings and errors to STDOUT not STDERR (re-opened)Continuing with #7107. Right now, it is impossible to run `apk` and only show success messages as warnings and errors are all send to stdout. Sure, I can pipe everything, check the exit code and print only on error, but this is less eleg...Continuing with #7107. Right now, it is impossible to run `apk` and only show success messages as warnings and errors are all send to stdout. Sure, I can pipe everything, check the exit code and print only on error, but this is less elegant. A custom flag that tells `apk` to be quite only on failed operations would also be insufficient, because `apk` shall be part of a wrapper function, so it should really send warnings and errors to the right output, so they can be handled properly higher up.
The original fix was reverted, because a user reported:
> If I run apk and get an error, the message is printed on the current
> line of my terminal and it disappears when I start typing.
I think this is a different issue that should be fixed properly, instead of just sending all output to stdout.
In addition to that, diagnostic infos should be send to stderr, as well, since they result of an error.
`apk add unknown-pkg-foo-baz 2>/dev/null` should be silent.
cc @fabledv3.0