apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2023-10-12T10:08:45Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10896apk3: apk search no longer shows reverse dependencies of non-existent packages2023-10-12T10:08:45ZDaniel Kolesaapk3: apk search no longer shows reverse dependencies of non-existent packagesEver since some point (not exactly sure when, probably when the `--from` stuff was added), `apk search` will no longer find reverse dependencies of a package that was dropped from index.
That means:
1) Given a (possibly only virtual) p...Ever since some point (not exactly sure when, probably when the `--from` stuff was added), `apk search` will no longer find reverse dependencies of a package that was dropped from index.
That means:
1) Given a (possibly only virtual) package `foo` which is no longer present in index
2) And package `bar` depending on it
3) Running `apk search -r -e foo` will no longer list `bar` like it did before
This does not apply to packages that *are* present in index. Example:
```
root@cbuild: ~$ apk search -r -e so:libLLVM-16.so
libllvm-16.0.2-r0 is required by:
llvm-runtime-16.0.2-r0
lld-16.0.2-r0
clang-16.0.2-r0
llvm-16.0.2-r0
clang-tools-extra-16.0.2-r0
libclang-cpp-16.0.2-r0
libllvm-dbg-16.0.2-r0
libclang-16.0.2-r0
llvm-linker-tools-16.0.2-r0
llvm-devel-16.0.2-r0
libomp-16.0.2-r0
lldb-16.0.2-r0
spirv-llvm-translator-16.0.0-r0
root@cbuild: ~$ apk search -r -e so:libLLVM-15.so
root@cbuild: ~$ apk info -R rust
rust-1.69.0-r0 depends on:
clang
musl-devel
rust-std=1.69.0-r0
so:libLLVM-15.so
so:libc++.so.1
so:libc.so
so:libunwind.so.1
```
Note how `rust` depends on `so:libLLVM-15.so` but it is seemingly impossible to look it up in reverse. The `apk info` command is identically affected. I noticed this when my package staging system seemingly stopped working.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10895ERROR: script exited with error 02024-03-08T16:21:40ZPatrycja Rosaalpine@ptrcnull.meERROR: script exited with error 0in some weird cases, like running an arm64v8 container on x86_64 with qemu-user, apk can return `script exited with error 0`:
```console
$ podman run --rm -it arm64v8/alpine:3.15
WARNING: image platform (linux/arm64/v8) does not match t...in some weird cases, like running an arm64v8 container on x86_64 with qemu-user, apk can return `script exited with error 0`:
```console
$ podman run --rm -it arm64v8/alpine:3.15
WARNING: image platform (linux/arm64/v8) does not match the expected platform (linux/amd64)
/ # sed -i 's/3.15/3.12/' /etc/apk/repositories
/ # apk upgrade -a
fetch https://dl-cdn.alpinelinux.org/alpine/v3.12/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.12/community/aarch64/APKINDEX.tar.gz
(1/15) Downgrading musl (1.2.2-r8 -> 1.1.24-r10)
(2/15) Downgrading busybox (1.34.1-r7 -> 1.31.1-r22)
Executing busybox-1.31.1-r22.post-upgrade
(3/15) Downgrading alpine-baselayout (3.2.0-r18 -> 3.2.0-r7)
Executing alpine-baselayout-3.2.0-r7.pre-upgrade
ERROR: alpine-baselayout-3.2.0-r7.pre-upgrade: script exited with error 0
Executing alpine-baselayout-3.2.0-r7.post-upgrade
(4/15) Downgrading alpine-keys (2.4-r1 -> 2.4-r0)
```
i narrowed it down to this line:
https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/v2.12.7/src/database.c#L1979
but couldn't find in which cases `WIFEXITED` would return a zero valuehttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/108942.14_rc1: fetch -L not recognised2023-10-12T10:08:45ZGhost User2.14_rc1: fetch -L not recognised```console
$ apk fetch -L musl
apk: unrecognized option: L
$ apk fetch --link musl # works
```
`apk fetch --help`:
```
-L, --link Create hard links if possible
``````console
$ apk fetch -L musl
apk: unrecognized option: L
$ apk fetch --link musl # works
```
`apk fetch --help`:
```
-L, --link Create hard links if possible
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10893apk dot exiting with code 1 and without any output2023-04-26T10:28:11ZPatrycja Rosaalpine@ptrcnull.meapk dot exiting with code 1 and without any outputsorry, this is a bit of a vague issue.
i still have no idea how to reproduce it, must be something broken with my world / installed dbsorry, this is a bit of a vague issue.
i still have no idea how to reproduce it, must be something broken with my world / installed dbhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10890[Question] Order of installation/upgrades for "install_if" packages2023-04-24T15:05:20ZPablo Correa Gomez[Question] Order of installation/upgrades for "install_if" packagesI asked in IRC, and I was redirected here. I apologize if this is not the right place to ask.
Regarding some problem in pmOS, I have some question about whether there is a warrantied order during both installations and upgrades. The mai...I asked in IRC, and I was redirected here. I apologize if this is not the right place to ask.
Regarding some problem in pmOS, I have some question about whether there is a warrantied order during both installations and upgrades. The main reason, is that we currently enable some system services of dependent packages on the `post-upgrade` scripts of some meta-packages. I have built apk-tools with `DEBUG_PRINT` and read some of the solver code, but I am still a bit confused about quite some of the solver bits, so I thought asking would be smart. I hope it's not too annoying. I am interested in the following circumstances:
* Install: if "a" -> depends -> "b" -> depends -> "c", is there a warranty that "c" will be installed before "b", before "a"? They way I understand the solver, and some debugging, this is the only one that I'm partially sure is like this.
* Upgrade of packages (assuming all of them upgraded): if "a" -> depends -> "b" -> depends -> "c", is there a warranty that "c" will be upgraded before "b", before "a"?
In a sense, these two situations are the ones we need so we can keep the `post-upgrade` scripts and can avoid using "triggers" instead. The ones below just influence how we should do the packaging:
* Install: if "a" -> depends -> "b", and "c" -> install_if -> "a"=ver, "b", is there any warranty regarding the installation order of "c"? So for example, that it will be installed before any package that depends on "a"? By experience I assume no, but just checking.
* Upgrade of packages (assuming all of them upgraded): if "a" -> depends -> "b", and "c" -> install_if -> "a"=ver, "b", is there any warranty regarding the upgrade order of "c"? So for example, that it will be upgraded before any package that depends on "a"? Again, by experience I guess no, but also just checking.
Thank you very much for your time :)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10889FIFO handling and embedded checksums2023-10-12T10:08:44ZAlex DenesFIFO handling and embedded checksums`abuild` creates no checksums for FIFO files that are packaged and `apk-tools` <= 2.14.0 complains about the FIFO files having no embedded checksum.
Minimal APKBUILD to replicate:
```
pkgname=fifo-test
pkgver=0.0.0
pkgrel=0
pkgdesc="F...`abuild` creates no checksums for FIFO files that are packaged and `apk-tools` <= 2.14.0 complains about the FIFO files having no embedded checksum.
Minimal APKBUILD to replicate:
```
pkgname=fifo-test
pkgver=0.0.0
pkgrel=0
pkgdesc="FIFO problem showcase"
url="null"
arch="noarch"
license="null"
makedepends="busybox"
source=""
builddir="$srcdir/"
options="!check"
package() {
mkdir -p "$pkgdir"
mkfifo "$pkgdir"/test
}
```
This can cause problems in cases such as pre-built s6-linux-init databases which contain service FIFOs.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10888prismlauncher : enable aarch642023-04-15T19:30:56Zexkcprismlauncher : enable aarch64Pls enable aarch64 in the prismlauncher's apk build.Btw There are a flatpka version of prismlauncher for aarch64.Pls enable aarch64 in the prismlauncher's apk build.Btw There are a flatpka version of prismlauncher for aarch64.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10886apk index --incremental2023-10-12T10:08:44ZNatanael Copaapk index --incrementalIt would be nice to be able to update the index without having all the repository locally so builders don't need to have the entire repository locally.It would be nice to be able to update the index without having all the repository locally so builders don't need to have the entire repository locally.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10885libboost_context.so required for nix2023-03-22T15:11:24ZGhost Userlibboost_context.so required for nixI tried to install nix. I turned off the comment for the edge repository in /etc/apk/repositories to get nix then:
doas apk add nix
ERROR: unable to select packages:
so:libboost_context.so.1.81.0 (no such package):
required by: n...I tried to install nix. I turned off the comment for the edge repository in /etc/apk/repositories to get nix then:
doas apk add nix
ERROR: unable to select packages:
so:libboost_context.so.1.81.0 (no such package):
required by: nix-2.13.2-r0[so:libboost_context.so.1.81.0]https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10884apk3: provider priority is not respected2023-10-12T10:08:44ZDaniel Kolesaapk3: provider priority is not respectedI created two packages, `testpkg-a` and `testpkg-b`. They both provide `testfoo` with an identical version, with `testpkg-a` having priority of 1 and `testpkg-b` having priority of 100.
adbdump for `testpkg-a`, showing it has the correc...I created two packages, `testpkg-a` and `testpkg-b`. They both provide `testfoo` with an identical version, with `testpkg-a` having priority of 1 and `testpkg-b` having priority of 100.
adbdump for `testpkg-a`, showing it has the correct priority and provides:
```
#%SCHEMA: 676B6370
# ADB block, size: 292, compat: 0, ver: 0
info:
name: testpkg-a
version: 0.1-r0
unique-id: c1be6a801cc49e691a96f5f12117ac300f13d0eb
description: Test package
arch: x86_64
license: custom:meta
origin: testpkg-a
maintainer: q66 <q66@chimera-linux.org>
url: https://chimera-linux.org
build-time: 1679187819
installed-size: 4096 B
priority: 1
provides: # 1 items
- testfoo=0.1-r0
paths: # 1 items
- acl:
mode: 755
user: root
group: root
# sig v00 h04 8d10a60e37e6ce5ec1ccec8752206cb61e14f90b5e8dbe823c794e6bc078a93235cfca9df149f3792061b4d595cb60c259cfe8522d99..: UNTRUSTED signature
```
adbdump for `testpkg-b`, showing the same:
```
#%SCHEMA: 676B6370
# ADB block, size: 304, compat: 0, ver: 0
info:
name: testpkg-b
version: 0.1-r0
unique-id: 8ce10ac4c5ef480b149024358d9908bce206e708
description: Test package
arch: x86_64
license: custom:meta
origin: testpkg-a
maintainer: q66 <q66@chimera-linux.org>
url: https://chimera-linux.org
build-time: 1679187819
installed-size: 4096 B
priority: 100
provides: # 1 items
- testfoo=0.1-r0
paths: # 1 items
- acl:
mode: 755
user: root
group: root
# sig v00 h04 8d10a60e37e6ce5ec1ccec8752206cb67ecd102f70341aee0ffba8f5162e0cc2c6b8e8255b98fcb58d45efcd9a3c18b75a50945b0825..: UNTRUSTED signature
```
since they have the same version, apk should use the priority as a tie-breaker, and install `testpkg-b` when requesting a `testfoo`. However, this is not the case:
```
$ apk add testfoo
(1/1) Installing testpkg-a (0.1-r0)
```https://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/10881slightly bizarre add/upgrade behaviour2023-03-01T12:56:16ZGhost Userslightly bizarre add/upgrade behaviouri don't have a good reproduction for this. what happens is:
- there is a prebuilt CI image that has some 'older' version of a package installed. in this case, the ncurses libraries.
- a CI run starts
- the image runs `apk update`. and t...i don't have a good reproduction for this. what happens is:
- there is a prebuilt CI image that has some 'older' version of a package installed. in this case, the ncurses libraries.
- a CI run starts
- the image runs `apk update`. and there are newer versions of the things already installed.
- the image then does `apk add` of a bunch of stuff that isn't already in `world`.
and it fails with:
```
ERROR: unable to select packages:
ncurses-terminfo-base-6.4_p20230218-r3:
breaks: libmenuw-6.4_p20230225-r0[ncurses-terminfo-base=6.4_p20230225-r0]
libformw-6.4_p20230225-r0[ncurses-terminfo-base=6.4_p20230225-r0]
satisfies: libpanelw-6.4_p20230218-r3[ncurses-terminfo-base=6.4_p20230218-r3]
libncursesw-6.4_p20230218-r3[ncurses-terminfo-base=6.4_p20230218-r3]
libncursesw-6.4_p20230218-r3:
breaks: ncurses-dev-6.4_p20230225-r0[libncursesw=6.4_p20230225-r0]
satisfies: python3-3.11.2-r0[so:libncursesw.so.6]
gettext-libs-0.21.1-r1[so:libncursesw.so.6]
libpanelw-6.4_p20230218-r3[so:libncursesw.so.6]
libmenuw-6.4_p20230225-r0[so:libncursesw.so.6]
pinentry-1.2.1-r0[so:libncursesw.so.6]
readline-8.2.001-r0[so:libncursesw.so.6]
libedit-20221030.3.1-r0[so:libncursesw.so.6]
libformw-6.4_p20230225-r0[so:libncursesw.so.6]
libpanelw-6.4_p20230218-r3:
breaks: ncurses-dev-6.4_p20230225-r0[libpanelw=6.4_p20230225-r0]
satisfies: python3-3.11.2-r0[so:libpanelw.so.6]
```
but, if the `apk add bunch of stuff` is preceded by `apk upgrade`, no errors happen. i don't know what causes this.
to be clear, i don't think there is anything invalid at all in the above packaging. the apkbuild for ncurses is [this](https://git.alpinelinux.org/aports/tree/main/ncurses/APKBUILD?id=0ad370efb53b5a388e82b62b21ec8733b34a7aad). strictly speaking, nothing actually conflicts here (between files/paths), upgrades work fine, etc. the failing CI job is https://gitlab.freedesktop.org/emersion/wlroots/-/jobs/37107011 .
once the CI image 'gets regenerated' so the already-installed packages are the same as the ones in the repositories, everything works fine. at that point, merely bumping the pkgrel with no changes on the above ncurses packages will get the same failure again, on starting the image and running `apk add some stuff`.
this /did/ work before. i think this is a regression in 2.12.11, but i can't point to anything because i don't have a good reproduction setup for this..
of course, merely running `upgrade` first fixes it, but as i understand it the mere `add` should also work?https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10880apk-version: x.0_preY is considered newer than x.02023-10-12T10:08:44ZPatrycja Rosaalpine@ptrcnull.meapk-version: x.0_preY is considered newer than x.0```
$ apk3 version -t '6.0_pre1' '6.0'
>
$ apk3 version -t '6.1_pre1' '6.1'
<
```
same happens on apk-tools 2.12.11```
$ apk3 version -t '6.0_pre1' '6.0'
>
$ apk3 version -t '6.1_pre1' '6.1'
<
```
same happens on apk-tools 2.12.11https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10878apk's lib/apk/db/scripts.tar is date/time-dependent2023-02-23T09:35:23ZPetr Tomanapk's lib/apk/db/scripts.tar is date/time-dependentThe **```apk```** command writes into the ```/lib/apk/db/scripts.tar``` file. The way ```tar``` works is that the resulting .tar archive takes into account not only the contents of the files packed but also their timestamps (and their or...The **```apk```** command writes into the ```/lib/apk/db/scripts.tar``` file. The way ```tar``` works is that the resulting .tar archive takes into account not only the contents of the files packed but also their timestamps (and their order).
Why could this be a problem? If you run a build that produces e.g. a Docker image on top of the alpine image where you simply do ```RUN apk add curl``` in the source Dockerfile, you get a different resulting image even though the ```curl``` apk is the same and the base alpine image (```FROM alpine:<tag>```) is the same. So, on the very same machine, with the same dependencies, but in a different moment in time, you get a different result.
This effectively means that apk doesn't act in a repeatable way (which may or may not be an intention from the creators of apk/alpine) but it is an issue when trying to make your builds **reproducible**. Please see https://reproducible-builds.org/docs/source-date-epoch/ (SOURCE_DATE_EPOCH) for some attempts how to address this. See also https://stackoverflow.com/questions/32997526/how-to-create-a-tar-file-that-omits-timestamps-for-its-contents how to avoid the time-sensitivity in the ```tar``` tool.
**Possible solutions**:
* instruct tar not to take file timestamps into account (i.e. globally)
* add a cmdline argument to apk that will do the trick above (i.e. only when the user needs so)
* perhaps use the epoch env var mentioned above
For more details how to reproduce, please assume the below Dockerfile:
```
FROM alpine:<fixed_tag>
RUN apk update && apk add --no-cache curl
```
and see the resulting images/containers, and the differences:
```
# build the images
docker build -t tmp_alpine:1 .
docker build -t tmp_alpine:2 .
# create containers but don't run them
docker create --name="tmp_1" tmp_alpine:1
docker create --name="tmp_2" tmp_alpine:2
# export to a tar
docker export tmp_1 -o export_1.tar
docker export tmp_2 -o export_2.tar
# extract
mkdir tmp_1
mkdir tmp_2
tar -xvf export_1.tar -C tmp_1
tar -xvf export_2.tar -C tmp_2
# diff (btw this doesn't work on a Mac cmdline)
diff -r --no-dereference tmp_1 tmp_2
```
The difference will be in the ```scripts.tar``` file - even though the files inside have the same contents, the .tar file itself has a different checksum:
```
~ tar -tvf tmp_1/layer/lib/apk/db/scripts.tar
-rwxr-xr-x 0 root root 131 Nov 24 19:06 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.post-install
-rwxr-xr-x 0 root root 1056 Nov 24 19:06 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.post-upgrade
-rwxr-xr-x 0 root root 546 Nov 24 19:06 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.trigger
-rwxr-xr-x 0 root root 56 Nov 24 19:06 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.pre-install
-rwxr-xr-x 0 root root 983 Nov 24 19:06 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.post-install
-rwxr-xr-x 0 root root 706 Nov 24 19:06 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.pre-upgrade
-rwxr-xr-x 0 root root 983 Nov 24 19:06 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.post-upgrade
-rwxr-xr-x 0 root root 42 Nov 24 19:06 glibc-bin-2.33-r0.Q1nxKJj3cqOPuthsgXHKenUAGLhEM=.trigger
-rwxr-xr-x 0 root root 137 Nov 24 19:06 ca-certificates-20191127-r5.Q1+3SNr5R52GfBxkXj9gkEr6QAWZw=.post-deinstall
-rwxr-xr-x 0 root root 72 Nov 24 19:06 ca-certificates-20191127-r5.Q1+3SNr5R52GfBxkXj9gkEr6QAWZw=.trigger
~ tar -tvf tmp_2/layer/lib/apk/db/scripts.tar
-rwxr-xr-x 0 root root 131 Nov 24 19:10 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.post-install
-rwxr-xr-x 0 root root 1056 Nov 24 19:10 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.post-upgrade
-rwxr-xr-x 0 root root 546 Nov 24 19:10 busybox-1.33.1-r6.Q1dgtiXUOjvBmrjmjNI1P/d9kQxBw=.trigger
-rwxr-xr-x 0 root root 56 Nov 24 19:10 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.pre-install
-rwxr-xr-x 0 root root 983 Nov 24 19:10 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.post-install
-rwxr-xr-x 0 root root 706 Nov 24 19:10 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.pre-upgrade
-rwxr-xr-x 0 root root 983 Nov 24 19:10 alpine-baselayout-3.2.0-r16.Q1UJtB9cNV4r+/VbxySkEei++qbho=.post-upgrade
-rwxr-xr-x 0 root root 42 Nov 24 19:10 glibc-bin-2.33-r0.Q1nxKJj3cqOPuthsgXHKenUAGLhEM=.trigger
-rwxr-xr-x 0 root root 137 Nov 24 19:10 ca-certificates-20191127-r5.Q1+3SNr5R52GfBxkXj9gkEr6QAWZw=.post-deinstall
-rwxr-xr-x 0 root root 72 Nov 24 19:10 ca-certificates-20191127-r5.Q1+3SNr5R52GfBxkXj9gkEr6QAWZw=.trigger
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10877"sh: out of range" error message when installing certain packages.2023-02-22T09:49:57ZShyam Sunder"sh: out of range" error message when installing certain packages.I've been noticing a strange error message pop up when adding certain packages (namely `postgresql14-client`, but there might be others) inside a docker container.
Command:
```
apk --no-cache add postgresql14-client
```
Response:
```s...I've been noticing a strange error message pop up when adding certain packages (namely `postgresql14-client`, but there might be others) inside a docker container.
Command:
```
apk --no-cache add postgresql14-client
```
Response:
```shell
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/community/x86_64/APKINDEX.tar.gz
(1/6) Installing postgresql-common (1.1-r3)
Executing postgresql-common-1.1-r3.pre-install
(2/6) Installing libpq (15.2-r0)
(3/6) Installing ncurses-terminfo-base (6.3_p20221119-r0)
(4/6) Installing ncurses-libs (6.3_p20221119-r0)
(5/6) Installing readline (8.2.0-r0)
(6/6) Installing postgresql14-client (14.7-r0)
Executing busybox-1.35.0-r29.trigger
Executing postgresql-common-1.1-r3.trigger
* Setting postgresql14 as the default version
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.17/main: No such file or directory
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.17/community: No such file or directory
sh: out of range
OK: 11 MiB in 21 packages
```
Note that despite the error message, the package does install fine, and I'm able to run its installed binaries (namely `pg_dump`) just fine.
I have confirmed that this issue can be reproduced on the `v3.15`, `v3.16`, `v3.17`, `edge`, and `latest` tags of the official Alpine Linux Docker images. Note that other packages, such as `apk --no-cache add bash` don't seem to generate this message.
Judging by the nature of the error, I'm suspecting that this is an error in APK, but let me know if this should bug be opened on the postgres package instead.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10876apk.static: --initdb without adding a package?2023-02-28T10:19:45ZKasper Kapk.static: --initdb without adding a package?unlike `apk add`, there is no `--initdb` option in `apk search`, `apk fetch`, `apk cache` etc. to initialize the db and directory structure in a fresh environment (different `--root` or running apk.static on e.g. debian). not even `apk f...unlike `apk add`, there is no `--initdb` option in `apk search`, `apk fetch`, `apk cache` etc. to initialize the db and directory structure in a fresh environment (different `--root` or running apk.static on e.g. debian). not even `apk fix`, `apk update` or `apk upgrade` help in this case. there is no top-level command to "(re-)initialize the apk environment idempotently" either.
so if we wanted to use `search`, `fetch`, `cache` or any other command _before_ the first `add`, it is simply not possible(!?). the workaround is wasteful: `add` some random package with `--initdb`, then perform the desired action. otherwise, depending on the command, we are either greeted with:
```
ERROR: Unable to lock database: No such file or directory
ERROR: Failed to open apk database: No such file or directory
```
or
```
WARNING: opening from cache http://dl-cdn.alpinelinux.org/alpine/edge/main: cache not available
WARNING: opening from cache http://dl-cdn.alpinelinux.org/alpine/edge/community: cache not available
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10875add PURL field to apkv3 package data2024-03-08T14:45:39ZAriadne Conillariadne@ariadne.spaceadd PURL field to apkv3 package dataSecurity scanners have issues with disambiguating distribution package names (which exist in a flat namespace) verses upstream package names. In Alpine, a notable example of this would be the lua packages, e.g. `lua5.1`, `lua5.2`, etc. ...Security scanners have issues with disambiguating distribution package names (which exist in a flat namespace) verses upstream package names. In Alpine, a notable example of this would be the lua packages, e.g. `lua5.1`, `lua5.2`, etc. In these cases, scanners are unable to deduce that `lua5.1` is equivalent to upstream `lua~5.1` (e.g. lua 5.1.x).
An emergent industry standard to allow for disambiguation is the [Package URL specification](https://github.com/package-url/purl-spec). We should store this data in APKs, to help the scanners disambiguate.
(This would also require us to add PURLs where needed in our package build recipes, e.g. aports et al. But this is out of scope for here.)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10872Command apk add needs its time to return a non zero exit code2023-01-21T20:04:34ZPantelis KaramolegkosCommand apk add needs its time to return a non zero exit code`Dockerfile`
```Dockerfile
FROM alpine:3.16
WORKDIR /home/test
COPY script.sh /tmp/
RUN chmod +x /tmp/script.sh \
&& /tmp/script.sh \
&& rm -f /tmp/script.sh
```
`script.sh`
```bash
#!/bin/sh
apk update
wget -q -O /etc/apk/key...`Dockerfile`
```Dockerfile
FROM alpine:3.16
WORKDIR /home/test
COPY script.sh /tmp/
RUN chmod +x /tmp/script.sh \
&& /tmp/script.sh \
&& rm -f /tmp/script.sh
```
`script.sh`
```bash
#!/bin/sh
apk update
wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.32-r0/glibc-2.32-r0.apk
apk add glibc-2.32-r0.apk
sleep 1
```
`docker build -t test-image . --no-cache --progress=plain` will succeed.
If however one comments out `sleep 1` it will fail.
The error is always there in the `docker build` logs
```
#8 5.418 ERROR: glibc-2.32-r0: trying to overwrite etc/nsswitch.conf owned by alpine-baselayout-data-3.2.0-r23.
#8 5.490 1 error; 15 MiB in 15 packages
#8 DONE 6.6s
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10871[apk-tools] apk search [-d] is case sensitive by default2023-10-12T10:08:44ZJustin[apk-tools] apk search [-d] is case sensitive by defaultapk search [-d] is case sensitive by default, which i think is a **bug**. example:
`apk search -d ntp` will not find chrony, but `apk search -d NTP` will find it.
either turn off the case sensitive, or add an option to ignore case.apk search [-d] is case sensitive by default, which i think is a **bug**. example:
`apk search -d ntp` will not find chrony, but `apk search -d NTP` will find it.
either turn off the case sensitive, or add an option to ignore case.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10870Cannot install packages with symlinks to FAT32 filesystems2023-01-16T17:14:39ZPatrycja Rosaalpine@ptrcnull.meCannot install packages with symlinks to FAT32 filesystemsin my specific case, having EFI system partition mounted at `/boot` and installing a package like `main/xen-hypervisor` fails on `symlinkat("xen-4.17.0.gz", 3, "boot/.apk...") = -1 EPERM` called from [here][1]
*technically* that's not a...in my specific case, having EFI system partition mounted at `/boot` and installing a package like `main/xen-hypervisor` fails on `symlinkat("xen-4.17.0.gz", 3, "boot/.apk...") = -1 EPERM` called from [here][1]
*technically* that's not an issue with apk itself - the package literally has a symlink and apk is just trying to do its job - but it would be nice if there was some kind of a workaround for it (or maybe a more helpful error message)
[1]: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/v2.12.10/src/io_archive.c#L382