apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2024-03-21T18:09:41Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10978wrong progress bar after critical system upgrade2024-03-21T18:09:41ZSertonixwrong progress bar after critical system upgradeI noticed that the progress bar after a critical system upgrade used `#` even though apk should have used the unicode characters.
My guess is that when apk calls itself without passing variables that haven't been exported.I noticed that the progress bar after a critical system upgrade used `#` even though apk should have used the unicode characters.
My guess is that when apk calls itself without passing variables that haven't been exported.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/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/10901Enhancement: Simplify the Makefile, don't delete it2024-03-20T19:41:57ZBharatvaj HemanthEnhancement: Simplify the Makefile, don't delete itHi I've been trying to build apk-tools on mac osx but couldn't using the recommended meson build tools. Had an issue with finding the openssl while compiling libfetch. Then I tried with `make` and it didn't work either.
I then wrote a M...Hi I've been trying to build apk-tools on mac osx but couldn't using the recommended meson build tools. Had an issue with finding the openssl while compiling libfetch. Then I tried with `make` and it didn't work either.
I then wrote a Makefile based on the meson.build file and finally I was able to build it for mac.
[Makefile](/uploads/8e594233fa5231bf07cd70bf868009a2/Makefile)
[config.mk](/uploads/4a973489f47456117c30512ff14b9d17/config.mk)
Since `apk` is such a fundamental part of the base system, and as meson requires a separate package of it's own and python. I suggest to keep the Makefile around instead of deleting in the 3.0.0 version. I would like to work on it and maintain it, if the core maintainers agree on this.https://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/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/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/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/10946who owns directory2024-03-19T12:58:43ZSertonixwho owns directoryThe who-owns functionality of apk doesn't seem to work with directories.
eg.
```sh
apk info -W /var/mail
```
results in
```
ERROR: /var/mail: Could not find owner package
```
but should result in
```
/var/mail is owned by alpine-baselay...The who-owns functionality of apk doesn't seem to work with directories.
eg.
```sh
apk info -W /var/mail
```
results in
```
ERROR: /var/mail: Could not find owner package
```
but should result in
```
/var/mail is owned by alpine-baselayout-3.4.3-r2
```
instead.
It does work for symlinks thought (see `/var/run`).https://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/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.https://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/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/10882apk-version: 8.2.0 > 8.2.0012024-03-12T18:00:18ZValery Ushakovapk-version: 8.2.0 > 8.2.001readline package was recently upgraded to patchlevel 1, from `pkgver=8.2.0` to `pkgver=8.2.001`. However apk doesn't consider it to be an upgrade, b/c:
```
$ apk version -t 8.2.0 8.2.001
>
```
The apk sources say that "Leading zero digi...readline package was recently upgraded to patchlevel 1, from `pkgver=8.2.0` to `pkgver=8.2.001`. However apk doesn't consider it to be an upgrade, b/c:
```
$ apk version -t 8.2.0 8.2.001
>
```
The apk sources say that "Leading zero digits get a special treatment", but don't elaborate.
As the result the last component gets token value -1 for single zero in "0" and -2 for two zeroes in "001" (with "1" left over as `TOKEN_DIGIT`).
(xref: initially reported as alpine/aports#14668)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10976Conflicting unversioned providers2024-03-12T11:18:48ZSertonixConflicting unversioned providersCurrently 2 packages providing the same name without specifying a version do not conflict. (I know that this is intentional.)
The problem is that some packages providing the same name should conflict but adding a version doesn't makes s...Currently 2 packages providing the same name without specifying a version do not conflict. (I know that this is intentional.)
The problem is that some packages providing the same name should conflict but adding a version doesn't makes sense.
An example from alpine is `busybox-binsh` and `dash-binsh` (and other `*-binsh` packages). They fail to install together since they include the same file. The packages should already conflict in the resolving phase.
This would improve the error message and would allow correct simulation (`-s`).
My proposal is to allow specifying a conflict with a name provided by a package itself:
```
depends="!/bin/sh"
provides="/bin/sh"
```
Changing the resolver to ignore a conflict with a package itself should be enough to get this working. (To be tested)https://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/10961apk audit ignoring owners in /etc/apk2024-03-11T17:53:38ZSertonixapk audit ignoring owners in /etc/apk`apk audit` seems to list all files in `/etc/apk` as added even though some are packaged.
All of these shouldn't be listed:
```
A etc/apk/protected_paths.d/ca-certificates.list
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-5261cecb....`apk audit` seems to list all files in `/etc/apk` as added even though some are packaged.
All of these shouldn't be listed:
```
A etc/apk/protected_paths.d/ca-certificates.list
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-5261cecb.rsa.pub
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-5243ef4b.rsa.pub
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-61666e3f.rsa.pub
A etc/apk/keys/alpine-devel@lists.alpinelinux.org-6165ee59.rsa.pub
```https://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/10977`apk add` tries to set directory permissions when running as non-root user2024-03-11T13:54:53Zleso-kn`apk add` tries to set directory permissions when running as non-root userFrom the apk-tools documentation:
> ```
> --no-chown
> Do not change file owner or group. By default apk will manage the file
> ownership when running as root. However, this option is turned on when
> running as non-root user, a...From the apk-tools documentation:
> ```
> --no-chown
> Do not change file owner or group. By default apk will manage the file
> ownership when running as root. However, this option is turned on when
> running as non-root user, as changing file ownership is not permitted
> by the system then.
> ```
#### Reproducing the error
```bash
# as a non-root user
$ mkdir -p test-sysroot/etc/apk/keys
$ uname -m > test-sysroot/etc/apk/arch
$ cp /etc/apk/repositories test-sysroot/etc/apk
# let's try to install vim
$ apk --root=$PWD/test-sysroot add --initdb --allow-untrusted vim
(1/6) Installing vim-common (9.1.0-r1)
(2/6) Installing musl (1.2.5-r0)
(3/6) Installing xxd (9.1.0-r1)
(4/6) Installing ncurses-terminfo-base (6.4_p20231125-r0)
(5/6) Installing libncursesw (6.4_p20231125-r0)
(6/6) Installing vim (9.1.0-r1)
ERROR: 71 errors updating directory permissions
OK: 32 MiB in 6 packages
```
#### Expected behaviour
After vim is installed `apk` should not try to set any permissions, as `--no-chown` is implicitly passed by running as a non-root user.
**Note:** Passing `--no-chown` explicitly results in the same behaviour.
#### Actual behaviour
`apk` tries to set to set directory permissions despite the `--no-chown` flag in [database.c:2101](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/6cd7f31d9bde79bb6361f2d2cbe37bfbafa342ea/src/database.c#L2101).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10954inaccurate return code / broken error propagation2024-03-11T13:54:53ZZach van Rijninaccurate return code / broken error propagation**example: broken error propagation**
Trigger exit codes do not appear to bubble up to calling applications, even if internally the `broken_script` [flag is set](https://git.adelielinux.org/adelie/apk-tools/-/blob/3890035c21e40aca7d5360...**example: broken error propagation**
Trigger exit codes do not appear to bubble up to calling applications, even if internally the `broken_script` [flag is set](https://git.adelielinux.org/adelie/apk-tools/-/blob/3890035c21e40aca7d5360bfc40e4b7ab9f10c50/src/package.c#L1036-1047).
In this example, we run one command that does not require elevated permissions, and one that does.
```
/ # adduser -D foo && cd /home/foo && su foo
~ $ mkdir x && apk add --root x --initdb && cp /etc/apk/repositories x/etc/apk
OK: 0 MiB in 0 packages
~ $ apk add --root x musl --allow-untrusted; echo $?
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
(1/1) Installing musl (1.2.4-r2)
OK: 0 MiB in 1 packages
0
~ $ apk add --root x mandoc --allow-untrusted; echo $?
(1/2) Installing zlib (1.2.13-r1)
(2/2) Installing mandoc (1.14.6-r8)
ERROR: 4 errors updating directory permissions
OK: 1 MiB in 3 packages
0
```
**example: inaccurate return code**
The `apk` return code may be inaccurate under certain circumstances, as it appears to rely on a combination of application runtime state as well as database state.
In this example, we run the same (problematic) command twice in a row. Under some circumstances, zero may be returned the first time, and a nonzero value on subsequent invocations.
```
/ # adduser -D foo && cd /home/foo && su foo
~ $ mkdir x && apk add --root x --initdb && cp /etc/apk/repositories x/etc/apk
OK: 0 MiB in 0 packages
~ $ apk add --root x ca-certificates --allow-untrusted; echo $?
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
(1/5) Installing musl (1.2.4-r2)
(2/5) Installing busybox (1.36.1-r5)
Executing busybox-1.36.1-r5.post-install
ERROR: busybox-1.36.1-r5.post-install: chroot: Operation not permitted
ERROR: busybox-1.36.1-r5.post-install: script exited with error 127
(3/5) Installing busybox-binsh (1.36.1-r5)
(4/5) Installing libcrypto3 (3.1.4-r1)
(5/5) Installing ca-certificates (20230506-r0)
ERROR: 33 errors updating directory permissions
Executing busybox-1.36.1-r5.trigger
ERROR: busybox-1.36.1-r5.trigger: chroot: Operation not permitted
ERROR: busybox-1.36.1-r5.trigger: script exited with error 127
Executing ca-certificates-20230506-r0.trigger
ERROR: ca-certificates-20230506-r0.trigger: chroot: Operation not permitted
ERROR: ca-certificates-20230506-r0.trigger: script exited with error 127
1 error; 6 MiB in 5 packages
1
~ $ apk add --root x ca-certificates --allow-untrusted; echo $?
2 errors; 6 MiB in 5 packages
2
```