alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2024-03-22T20:14:48Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10883apk3: strange output behavior with install_if packages when trying to "add" a...2024-03-22T20:14:48ZDaniel Kolesaapk3: strange output behavior with install_if packages when trying to "add" a non-existent packageMy distribution makes heavy use of install_if, and it generally works well. This is just a harmless but annoying issue with invalid output, with the practical behavior with correct inputs being good.
Since it's hard to explain what's ac...My distribution makes heavy use of install_if, and it generally works well. This is just a harmless but annoying issue with invalid output, with the practical behavior with correct inputs being good.
Since it's hard to explain what's actually going on, here is a way to reproduce it:
```
$ mkdir testroot
$ apk --root testroot --repository "https://repo.chimera-linux.org/current/main" --allow-untrusted --initdb add chimerautils
fetch https://repo.chimera-linux.org/current/main/x86_64/APKINDEX.tar.gz
(1/16) Installing base-files (0.1-r0)
(2/16) Installing iana-etc (20230313-r0)
(3/16) Installing musl (1.2.3-r0)
(4/16) Installing libbz2 (1.0.8-r0)
(5/16) Installing libcxx (15.0.7-r0)
(6/16) Installing libcrypto3 (3.1.0-r0)
(7/16) Installing ncurses-libs (6.4-r0)
(8/16) Installing ncurses-base (6.4-r0)
(9/16) Installing ncurses (6.4-r0)
(10/16) Installing libedit (20220411-r0)
(11/16) Installing musl-fts (1.2.7-r0)
(12/16) Installing liblzma (5.4.1-r0)
(13/16) Installing musl-rpmatch (1.0-r0)
(14/16) Installing libxo (1.6.0-r0)
(15/16) Installing zlib (1.2.13-r0)
(16/16) Installing chimerautils (13.1.2-r0)
OK: 13 MiB in 16 packages
$ mount --bind /proc testroot/proc
$ mount --bind /sys testroot/sys
$ mount --bind /dev testroot/dev
$ cp /etc/resolv.conf testroot/etc
$ apk --root testroot --repository "https://repo.chimera-linux.org/current/main" --allow-untrusted add base-bootstrap
(1/7) Installing debianutils (5.7-r0)
(2/7) Installing libssl3 (3.1.0-r0)
(3/7) Installing openssl (3.1.0-r0)
(4/7) Installing ca-certificates (20230311-r0)
(5/7) Installing apk-tools (3.0.0_pre0-r0)
(6/7) Installing chimera-repo-main (0.1-r0)
(7/7) Installing base-bootstrap (0.1-r0)
Executing ca-certificates-20230311-r0.trigger
Clearing symlinks in /etc/ssl/certs...
done.
Updating certificates in /etc/ssl/certs...
157 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
OK: 16 MiB in 23 packages
$ chroot testroot /bin/sh
# apk update
fetch https://repo.chimera-linux.org/current/main/x86_64/APKINDEX.tar.gz
[https://repo.chimera-linux.org/current/main]
OK: 3315 distinct packages available
# apk add foobar
ERROR: unable to select packages:
foobar (no such package):
required by: world[foobar]
# apk add dinit-chimera
(1/17) Installing awk (20220303-r0)
(2/17) Installing libblkid (2.38.1-r0)
(3/17) Installing libmount (2.38.1-r0)
(4/17) Installing libsmartcols (2.38.1-r0)
(5/17) Installing util-linux-common (2.38.1-r0)
(6/17) Installing mount (2.38.1-r0)
(7/17) Installing kmod (30-r0)
(8/17) Installing procps (4.0.3-r0)
(9/17) Installing libcap (2.67-r0)
(10/17) Installing libkmod (30-r0)
(11/17) Installing udev (253-r0)
(12/17) Installing base-udev (253-r0)
(13/17) Installing udev-dinit (253-r0)
(14/17) Installing udev-dinit-links (253-r0)
(15/17) Installing dinit (0.16.1-r0)
(16/17) Installing tzdata (2022g-r0)
(17/17) Installing dinit-chimera (0.11-r0)
Executing udev-253-r0.trigger
Updating udev hwdb...
OK: 36 MiB in 40 packages
# apk add foobar
ERROR: unable to select packages:
foobar (no such package):
required by: world[foobar]
udev-dinit (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: udev-dinit
required by: udev-dinit-links-253-r0[udev-dinit=253-r0]
# apk add base-man
(1/21) Installing less (608-r0)
(2/21) Installing less-man (608-r0)
(3/21) Installing mandoc (1.14.6-r0)
(4/21) Installing mandoc-man (1.14.6-r0)
(5/21) Installing base-man (1.14.6-r0)
(6/21) Installing debianutils-man (5.7-r0)
(7/21) Installing openssl-man (3.1.0-r0)
(8/21) Installing libedit-man (20220411-r0)
(9/21) Installing chimerautils-man (13.1.2-r0)
(10/21) Installing apk-tools-man (3.0.0_pre0-r0)
(11/21) Installing ncurses-man (6.4-r0)
(12/21) Installing ca-certificates-man (20230311-r0)
(13/21) Installing musl-man (1.2.3-r0)
(14/21) Installing libxo-man (1.6.0-r0)
(15/21) Installing awk-man (20220303-r0)
(16/21) Installing mount-man (2.38.1-r0)
(17/21) Installing kmod-man (30-r0)
(18/21) Installing procps-man (4.0.3-r0)
(19/21) Installing udev-man (253-r0)
(20/21) Installing dinit-man (0.16.1-r0)
(21/21) Installing dinit-chimera-man (0.11-r0)
Executing mandoc-1.14.6-r0.trigger
Regenerating man db...
OK: 44 MiB in 61 packages
# apk add foobar
ERROR: unable to select packages:
foobar (no such package):
required by: world[foobar]
ncurses (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: ncurses
required by: ncurses-man-6.4-r0[ncurses=6.4-r0]
udev-dinit (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: udev-dinit
required by: udev-dinit-links-253-r0[udev-dinit=253-r0]
```
In this case, you can see the issue with the `ncurses` and `udev-dinit` packages. Both packages are real (non-virtual) but are automatically installed. Adding them into world makes them disappear from the list. The `udev-dinit` is also automatically installed by `install_if`, but `ncurses` is not. However, `ncurses-man` is automatically installed by `install_if`, as is `udev-dinit-links`, so the shared thing is that both are implicitly-installed packages treated as dependencies of automatically installed `install_if` packages (though in this case, `ncurses` would be installed by other things even if not a dependency of an `install_if` package).
In larger, more practical systems, this list can get massive, spamming the terminal output when a user makes a typo in package name they are installing. Technically it does not do any other harm, but it's still a UX problem.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10943odd/dangerous behavior with replaces= when reverting to previous package2024-03-22T20:14:48ZDaniel Kolesaodd/dangerous behavior with replaces= when reverting to previous packageif package A replaces B and they provide the same virtual package and B is installed by default, installing A works fine (it will replace B and B will get purged)
however, when trying to switch back to B, you need to go through somethin...if package A replaces B and they provide the same virtual package and B is installed by default, installing A works fine (it will replace B and B will get purged)
however, when trying to switch back to B, you need to go through something like, delete A from world first (that by itself will not do anything) and then install B again; apk will do that, but it will erase the files that were replaced in the process (because B will be installed, then A will be purged which will remove the replaced files, and then you have to manually fix B afterwards)
the most notable case in my case is multiple providers for libc; installing a secondary libc provider will be fine, but you can't restore the original libc without static apk or external system, as restoring the previous libc will erase your libc.so, and everything will stop workingv3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10904reinstalls are somewhat broken if original directories are missing2024-03-22T14:06:35ZDaniel Kolesareinstalls are somewhat broken if original directories are missingThe current behavior of `apk fix` is somewhat broken. When you delete a package's directory tree and then `apk fix` it, you will get messages like:
```
ERROR: Failed to create /path/to/some/file: No such file or directory
```
This is b...The current behavior of `apk fix` is somewhat broken. When you delete a package's directory tree and then `apk fix` it, you will get messages like:
```
ERROR: Failed to create /path/to/some/file: No such file or directory
```
This is because apk does not re-create the directory structure to put the file in, and then tries to put the file in there, which causes the errors. This makes e.g. reinstalling packages on broken systems where stuff got deleted rather inconvenient.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10973apk3: unversioned virtual providers are broken2024-03-20T19:28:11ZDaniel Kolesaapk3: unversioned virtual providers are brokenI created 3 packages, `testp`, `testq`, and `testr`. The first two provide an unversioned name `foopkg` while the latter depends on it.
Trying to install `testr` behaves correctly at first:
```
root@cbuild: ~$ apk add testr
ERROR: unab...I created 3 packages, `testp`, `testq`, and `testr`. The first two provide an unversioned name `foopkg` while the latter depends on it.
Trying to install `testr` behaves correctly at first:
```
root@cbuild: ~$ apk add testr
ERROR: unable to select packages:
foopkg (virtual):
note: please select one of the 'provided by' packages explicitly
provided by: testp testq
required by: testr-0.1-r0[foopkg]
```
I get asked to select one of the providers. I install one:
```
root@cbuild: ~$ apk add testp
The following NEW packages will be installed:
testp
After this operation, 4096 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Installing testp (0.1-r0)
OK: 606 MiB in 57 packages
```
However, when I try to install `testr` again after that, I get the following:
```
root@cbuild: ~$ apk add testr
ERROR: unable to select packages:
testp-0.1-r0:
breaks: testr-0.1-r0[foopkg]
satisfies: world[testp]
```
Installing the other provider as well breaks in the same way:
```
root@cbuild: ~$ apk add testq
The following NEW packages will be installed:
testq
After this operation, 4096 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(1/1) Installing testq (0.1-r0)
OK: 606 MiB in 58 packages
root@cbuild: ~$ apk add testr
ERROR: unable to select packages:
testp-0.1-r0:
breaks: testr-0.1-r0[foopkg]
satisfies: world[testp]
testq-0.1-r0:
breaks: testr-0.1-r0[foopkg]
satisfies: world[testq]
```
The dependency specifications are fine:
```
root@cbuild: ~$ apk info --provides testp
testp-0.1-r0 provides:
foopkg
root@cbuild: ~$ apk info --provides testq
testq-0.1-r0 provides:
foopkg
root@cbuild: ~$ apk info --depends testr
testr-0.1-r0 depends on:
foopkg
```
Specifying the provider at add time does not help either:
```
root@cbuild: ~$ apk add testr testp
ERROR: unable to select packages:
testp-0.1-r0:
breaks: testr-0.1-r0[foopkg]
satisfies: world[testp]
testq-0.1-r0:
breaks: testr-0.1-r0[foopkg]
satisfies: world[testq]
```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/10974apk3: --no-chown should skip over failed xattrs2024-03-11T15:10:37ZDaniel Kolesaapk3: --no-chown should skip over failed xattrsCurrently when a package has xattrs and the xattr setting fails (e.g. for security attributes), this prevents installation of the package with --no-chown when running apk as not root. It should probably ignore failed xattrs in that case.Currently when a package has xattrs and the xattr setting fails (e.g. for security attributes), this prevents installation of the package with --no-chown when running apk as not root. It should probably ignore failed xattrs in that case.v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10907apk policy listing packages in wrong order2024-03-08T16:21:40ZEdward Peekapk policy listing packages in wrong orderPer `apk policy --help` packages are supposed to be listed "in order of installation preference".
In Alpine 3.18 with `apk-tools-2.14.0-r2` I am instead observing multiple versions of the same package from a single custom repo being lis...Per `apk policy --help` packages are supposed to be listed "in order of installation preference".
In Alpine 3.18 with `apk-tools-2.14.0-r2` I am instead observing multiple versions of the same package from a single custom repo being listed unsorted in whatever order they are defined in the repo index. The first result is not what is installed:
```
# apk policy libuuid
libuuid policy:
2.38.1-r7:
https://.../v3.18/main
2.38.1-r8:
https://.../v3.18/main
/ # apk add libuuid
WARNING: This apk-tools is OLD! Some packages might not function properly.
(1/1) Installing libuuid (2.38.1-r8)
OK: 7 MiB in 16 packages
```
The repo `APKINDEX` contains:
```
P:libuuid
V:2.38.1-r7
A:x86_64
S:13571
I:40960
T:DCE compatible Universally Unique Identifier library
U:https://git.kernel.org/cgit/utils/util-linux/util-linux.git
L:BSD-3-Clause
o:util-linux
m:Natanael Copa <ncopa@alpinelinux.org>
t:1681557467
c:25bd220db5fce58966f17cf7719f9c73a5c5295e
D:so:libc.musl-x86_64.so.1
p:so:libuuid.so.1=1.3.0
z:v3.18/main/x86_64/libuuid-2.38.1-r7.apk
y:fbcdcb907098b719a1a7dd21aa48ddce83e8b62c
P:libuuid
V:2.38.1-r8
A:x86_64
S:13567
I:40960
T:DCE compatible Universally Unique Identifier library
U:https://git.kernel.org/cgit/utils/util-linux/util-linux.git
L:BSD-3-Clause
o:util-linux
m:Natanael Copa <ncopa@alpinelinux.org>
t:1686107202
c:c7de7fac9ae57f268781a733984e74a36f867d1c
D:so:libc.musl-x86_64.so.1
p:so:libuuid.so.1=1.3.0
```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/10903apk3: broken adb with files over 1073741811 bytes2023-10-15T16:40:28ZDaniel Kolesaapk3: broken adb with files over 1073741811 bytesThe following code:
```
struct adb_block blk = adb_block_init(ADB_BLOCK_DATA, size + hdr.len);
size_t padding = adb_block_padding(&blk);
int r;
```
Using files of sizes larger than 1073741811 bytes will result in a block of type `AD...The following code:
```
struct adb_block blk = adb_block_init(ADB_BLOCK_DATA, size + hdr.len);
size_t padding = adb_block_padding(&blk);
int r;
```
Using files of sizes larger than 1073741811 bytes will result in a block of type `ADB_BLOCK_DATAX`, as the file will have spilled into the block's type bits. That will result in errors about bad ADB block when trying to check or extract the files.
It should be very easy to reproduce, the solution should probably using some kind of chunked approach for files whose size including the header does not fit in 30 bits.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/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/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/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/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/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/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/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/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/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.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.0