apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2019-07-14T07:53:02Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7162`apk update` attempts mount/umount2 when run with rkt2019-07-14T07:53:02ZTim Dettrick`apk update` attempts mount/umount2 when run with rkt[rkt](https://github.com/rkt/rkt) is a container engine similar to
Docker, and capable of running Docker images. Like Docker, it enforces
seccomp and capability restrictions on system calls.
Alpine Edge has recently broken \`apk update\...[rkt](https://github.com/rkt/rkt) is a container engine similar to
Docker, and capable of running Docker images. Like Docker, it enforces
seccomp and capability restrictions on system calls.
Alpine Edge has recently broken \`apk update\` functionality with rkt,
as it is issuing (unnecessary) mount/umount2 syscalls which are blocked
by seccomp.
$ sudo rkt run --dns 8.8.8.8 --insecure-options image docker://alpine:3.5 --exec /bin/sh -- -c "apk --version && apk update"
[ 5844.906525] alpine[5]: apk-tools 2.6.8, compiled for x86_64.
[ 5844.908101] alpine[5]: fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/x86_64/APKINDEX.tar.gz
[ 5846.799587] alpine[5]: fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/community/x86_64/APKINDEX.tar.gz
[ 5847.041904] alpine[5]: v3.5.2-46-gdf4d97eba7 [http://dl-cdn.alpinelinux.org/alpine/v3.5/main]
[ 5847.042149] alpine[5]: v3.5.2-47-ga46d5990dc [http://dl-cdn.alpinelinux.org/alpine/v3.5/community]
[ 5847.042290] alpine[5]: OK: 7959 distinct packages available
$ sudo rkt run --dns 8.8.8.8 --insecure-options image docker://alpine:edge --exec /bin/sh -- -c "apk --version && apk update"
[ 5851.405934] alpine[5]: apk-tools 2.7.0, compiled for x86_64.
[ 5851.407383] alpine[5]: Bad system call
Please see [rkt/rkt\#3642](https://github.com/rkt/rkt/issues/3642) for
more detail.
I believe the most likely cause is the revised /proc setup logic.
*(from redmine: issue id 7162, created on 2017-04-18, closed on 2019-05-03)*
* Changesets:
* Revision 7ee47c808bdda24a658b325f229a2a8b84fe3790 by Timo Teräs on 2017-10-10T08:38:52Z:
```
db: handle default root correctly for /proc
dbopts->root may be null; use db->root instead
fixes #7162
```
* Revision 97e4d0531f2633b54996fc08447bb46449f4a45a by Timo Teräs on 2017-10-10T08:39:38Z:
```
db: handle default root correctly for /proc
dbopts->root may be null; use db->root instead
fixes #7162
```
* Revision 0e504ac58e35f837c468884de7bd4d5d005acd66 by Timo Teräs on 2017-10-10T10:41:21Z:
```
main/apk-tools: fix mounting proc (fixes #7162)
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7104[subset of #7103] Extract manifest of pax checksum headers vs. files for apks...2022-12-21T19:47:14ZChris Giorgi[subset of #7103] Extract manifest of pax checksum headers vs. files for apks to stdout.This particular portion of Feature \#7103 is needed immediately to
improve user experience in upcoming Alpine 3.6 release.
In order to verify integrity of files extracted from apks and uniquely
identify specific versions of a file, the ...This particular portion of Feature \#7103 is needed immediately to
improve user experience in upcoming Alpine 3.6 release.
In order to verify integrity of files extracted from apks and uniquely
identify specific versions of a file, the checksum stored in the pax
header
68 APK-TOOLS.checksum.SHA1=
needs to be retrieved for each file in the apk tar archive. No standard
tar tool can extract this information, and using an awk script results
in unreasonably long runtimes for large packages such as ‘linux-grsec’,
‘linux-firmware’, etc.
apk already reads these headers, but there is currently no way to expose
that information.
Proposed functionality is export of a manifest to stdout (or optionally
file) containing one line per file (with optional comments), and each
line having information to uniquely identify a file by arch, package
name, and full package version.
Format currently in use in kerneltool/mkimage project is
printf 'apk:%s/%s-%s\t%s:$s\t%s' $arch $pkgname $pkgver $sumtype $sum $filename
where $sumtype is the lowercase name of the checksum function, such as
‘sha1’, ‘sha512’, or ‘md5’, which, when prepended to ‘sum’, yields the
appropriate command to verify the sum (i.e. ‘sha1’ ->sha1sum)
*(from redmine: issue id 7104, created on 2017-04-08)*https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7100apk should support the use of full '$pkgname-$pkgver' atom as returned by 'ap...2024-03-22T11:45:14ZChris Giorgiapk should support the use of full '$pkgname-$pkgver' atom as returned by 'apk search -x $pkgname' everywhere '$pkgname' is usedCurrently, apk does not consider a full package atom, including version
($pkgname-$pkgver) to match a package which matches that exact atom.
For instance:
# apk search -x linux-grsec
linux-grsec-4.9.20-r0
# apk search -x $...Currently, apk does not consider a full package atom, including version
($pkgname-$pkgver) to match a package which matches that exact atom.
For instance:
# apk search -x linux-grsec
linux-grsec-4.9.20-r0
# apk search -x $(apk search -x linux-grsec)
#
This issue is present in all places where apk expects a $pkgname and
receives a complete atom in the format returned by ‘apk search -x
$pkgname’.
This behavior is counter-intuitive and leads to significant additional
effort being required in parsing within scripts calling apk to strip the
version, perform an operation with apk, then check the version actually
retrieved.
apk should accept the full atom as returned by ‘apk search -x’, and
throw an error if the version specified doesn’t match the available
$pkgver.
*(from redmine: issue id 7100, created on 2017-04-07)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/6795segmentation fault in apk.static from Alpine 3.5 blocks build on armhf2019-07-14T07:41:23ZTianon Gravisegmentation fault in apk.static from Alpine 3.5 blocks build on armhfThis appears to be very similar to
https://bugs.alpinelinux.org/issues/6372 on the surface, although
underlying cause might not be (there’s less output from `apk.static`
before the segfault here than there is there).
Here’s the script o...This appears to be very similar to
https://bugs.alpinelinux.org/issues/6372 on the surface, although
underlying cause might not be (there’s less output from `apk.static`
before the segfault here than there is there).
Here’s the script output: (note that `apk` referenced here is actually a
copy of `apk.static` from the `apk-tools-static-2.6.8-r1` package, and
`/home/ubuntu/jenkins-slave/workspace/docker-armhf-alpine/apk-tools-v3.5/etc/apk/keys`
comes from the `alpine-keys-1.3-r0` package)
$ sudo PATH="$PATH" ./mkimage-alpine.bash "${BUILD_OPTIONS[@]}"
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/armhf/APKINDEX.tar.gz
./mkimage-alpine.bash: line 21: 14229 Segmentation fault (core dumped) apk --root "$rootfs" --update-cache --keys-dir /home/ubuntu/jenkins-slave/workspace/docker-armhf-alpine/apk-tools-v3.5/etc/apk/keys add --initdb ${packages[*]//,/ }
A `gdb` backtrace was requested in
https://bugs.alpinelinux.org/issues/6372\#note-24, but I can’t seem to
find where the core file was dumped, and running `apk` directly via
`gdb` is giving me the following:
Reading symbols from /home/ubuntu/jenkins-slave/workspace/docker-armhf-alpine/apk-tools-v3.5/sbin/apk.static...(no debugging symbols found)...done.
(gdb) r
Starting program: /home/ubuntu/jenkins-slave/workspace/docker-armhf-alpine/apk-tools-v3.5/sbin/apk.static --root /var/tmp/alpine-docker-rootfs-9n21sOwkbI --update-cache --keys-dir /home/ubuntu/jenkins-slave/workspace/docker-armhf-alpine/apk-tools-v3.5/etc/apk/keys add --initdb alpine-baselayout alpine-keys apk-tools libc-utils
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/armhf/APKINDEX.tar.gz
Program received signal SIGSEGV, Segmentation fault.
0xaab02e1c in ?? ()
(gdb) bt
#0 0xaab02e1c in ?? ()
#1 0xaab03008 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
I’m happy to do more to help debug further — just need some pointers. :)
It might also be notable that 3.2, 3.3, 3.4, and edge all work fine in
the same environment.
*(from redmine: issue id 6795, created on 2017-02-01, closed on 2017-05-22)*
* Changesets:
* Revision 0eb056df5f4e6fb5af12c3f3f8eef81100066b02 by Natanael Copa on 2017-02-02T06:41:14Z:
```
main/apk-tools: fix error message short read
also triggers rebuild which might fix apk.static (ref #6795)
(cherry picked from commit 5ef7a332f8186986761c3280b8b2c2bf1c02f230)
```
* Revision 3a1f5351fc414b87eed5250b25df8e35f3973ddc by Natanael Copa on 2017-05-09T19:39:25Z:
```
main/apk-tools: fix error message short read
also triggers rebuild which might fix apk.static (ref #6795)
(cherry picked from commit 5ef7a332f8186986761c3280b8b2c2bf1c02f230)
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/6591APK is executing scripts inside /var/cache, and it prevents normal operation2022-02-24T12:39:57ZJakub SkrzypnikAPK is executing scripts inside /var/cache, and it prevents normal operationHello,
I was trying complex ZFS pools, so I added the /var/cache as separate
ZFS volume.
As security mesaure, I’ve disabled execution on it, to reduce attack
surface.
And it broke APK:
ERROR: packagename }}-{{packageversion : s...Hello,
I was trying complex ZFS pools, so I added the /var/cache as separate
ZFS volume.
As security mesaure, I’ve disabled execution on it, to reduce attack
surface.
And it broke APK:
ERROR: packagename }}-{{packageversion : script exited with error 1
From some debugging I’ve figured out that APK executes post/pre-install
scripts inside /var/cache directly after unpacking .apk files.
PROPOSED SOLUTION: Move the unpacking and processing phase into /tmp,
remove files after processing
*(from redmine: issue id 6591, created on 2016-12-27)*
* Relations:
* relates #129Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/6372segmentation fault in apk.static at 2.6.7 blocks build on aarch642019-07-14T07:40:27ZEdward Vielmettisegmentation fault in apk.static at 2.6.7 blocks build on aarch64On ARMv8 (aarch64) the “apk.static” binary at 2.6.7 crashes with a
“segmentation fault” when you attempt to build a Docker image for it
from the script at
https://github.com/docker/docker/blob/master/contrib/mkimage-alpine.sh .
This make...On ARMv8 (aarch64) the “apk.static” binary at 2.6.7 crashes with a
“segmentation fault” when you attempt to build a Docker image for it
from the script at
https://github.com/docker/docker/blob/master/contrib/mkimage-alpine.sh .
This makes it impossible to build the aarch64/alpine Docker image.
Replicate by getting Docker source, then running the
“contrib/mkimage-alpine.sh” script.
root@armv8hello:/var/tmp/alpine-docker-y2oEFmD4Ye/sbin\# ./apk.static
—version
apk-tools 2.6.7, compiled for aarch64.
I’m not sure precisely how the apk.static binary is being called, and I
haven’t been able to isolate a minimum repeat of this. Noting however
that the http://git.alpinelinux.org/cgit/apk-tools repository has an
update after 2.6.7 that is specific to aarch64 which might possibly be
related (it’s at
http://git.alpinelinux.org/cgit/apk-tools/commit/?id=06ae5fdfdccd0c8e6d5501d93666bd915d2604d1
).
I can provide access to an ARMv8 system to replicate this.
Transcript:
emv@armv8hello:~/src/docker/contrib$ sudo ./mkimage-alpine.sh
tar: Ignoring unknown extended header keyword
‘APK-TOOLS.checksum.SHA1’
tar: Ignoring unknown extended header keyword
‘APK-TOOLS.checksum.SHA1’
fetch
http://nl.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz
(1/16) Installing musl (1.1.15-r4)
(2/16) Installing busybox (1.25.1-r0)
Executing busybox-1.25.1-r0.post-install
(3/16) Installing alpine-baselayout (3.0.3-r2)
Executing alpine-baselayout-3.0.3-r2.pre-install
Executing alpine-baselayout-3.0.3-r2.post-install
(4/16) Installing openrc (0.21.7-r1)
Executing openrc-0.21.7-r1.post-install
(5/16) Installing alpine-conf (3.4.1-r5)
(6/16) Installing libressl2.4-libcrypto (2.4.3-r1)
(7/16) Installing libressl2.4-libssl (2.4.3-r1)
(8/16) Installing zlib (1.2.8-r2)
(9/16) Installing apk-tools (2.6.7-r2)
(10/16) Installing busybox-suid (1.25.1-r0)
(11/16) Installing busybox-initscripts (3.0-r6)
Executing busybox-initscripts-3.0-r6.post-install
(12/16) Installing scanelf (1.1.6-r0)
(13/16) Installing musl-utils (1.1.15-r4)
(14/16) Installing libc-utils (0.7-r1)
(15/16) Installing alpine-keys (1.2-r0)
(16/16) Installing alpine-base (3.4.0-r0)
Executing busybox-1.25.1-r0.trigger
OK: 5 MiB in 16 packages
Segmentation fault
*(from redmine: issue id 6372, created on 2016-10-21, closed on 2017-05-22)*
* Changesets:
* Revision c9e1d3182f84e917a20d1836b163082455a8eb6b by Timo Teräs on 2016-10-25T17:51:24Z:
```
main/gcc: add ld -Bsymbolic for static pie linking
ref #6372
```
* Revision 6ae8e4414d963c8812c86c2eb0d26c2434a93bec by Timo Teräs on 2016-10-25T19:16:33Z:
```
main/apk-tools: rebuild with fixed gcc
fixes #6372
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/6081apk info --depends is slow2022-12-21T18:50:51Zalgitbotapk info --depends is slow*(from redmine: issue id 6081, created on 2016-08-25)**(from redmine: issue id 6081, created on 2016-08-25)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5977Parallel Downloads for "apk add"2024-02-23T12:34:41ZNoah NordrumParallel Downloads for "apk add"I think it would be great to have the option to do parallel downloads of
packages, with a configurable amount of threads. Something like “apk
—no-cache —parallel=8 add openjdk8”. (with a default of 1)
You could also grab the various AP...I think it would be great to have the option to do parallel downloads of
packages, with a configurable amount of threads. Something like “apk
—no-cache —parallel=8 add openjdk8”. (with a default of 1)
You could also grab the various APKINDEXes using that same thread pool.
If you didn’t want to hammer the CDNs, you could add a hard-coded
exemption to \*.alpinelinux.org or something.
I’m running a local mirror of dl-cdn.alpinelinux.org, so I would really
like to take advantage of my internal bandwidth.
Since all the dependency information is in APKINDEX, I would think it
wouldn’t be too painful to throw it in a prioritized queue and delegate
to an executor of some kind, but I haven’t looked at the internals
(yet).
*(from redmine: issue id 5977, created on 2016-07-27)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5369Add support for LZ42024-02-19T15:48:48ZCarlo LandmeterAdd support for LZ4According to the author on: https://github.com/Cyan4973/lz4 lz4
decompresses almost by a factor 7 compared to zlib while keeping
compression at similar level.
Would this be an possible candidate to replace zlib in apk?
*(from redmine...According to the author on: https://github.com/Cyan4973/lz4 lz4
decompresses almost by a factor 7 compared to zlib while keeping
compression at similar level.
Would this be an possible candidate to replace zlib in apk?
*(from redmine: issue id 5369, created on 2016-04-05)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5076Long symbolic links (> 100 chars) get their target file names truncated when ...2019-07-14T07:37:40ZJonathan CurranLong symbolic links (> 100 chars) get their target file names truncated when a pkg containing them is added `apk add`While working on the mono APK I ran into this issue where when the apk
is being installed, the symbolic link target file names were getting
truncated at 100 chars.
> sudo apk add ~/packages/testing/x86_64/mono-4.2.2.30-r1.apk
> ...While working on the mono APK I ran into this issue where when the apk
is being installed, the symbolic link target file names were getting
truncated at 100 chars.
> sudo apk add ~/packages/testing/x86_64/mono-4.2.2.30-r1.apk
> find /usr/lib/mono/4.5/ -xtype l | xargs ls -l
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/Mono.CompilerServices.SymbolWriter.dll -> ../gac/Mono.CompilerServices.SymbolWriter/4.0.0.0__0738eb9f132ed756/Mono.CompilerServices.SymbolWrit
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.ComponentModel.Composition.dll -> ../gac/System.ComponentModel.Composition/4.0.0.0__b77a5c561934e089/System.ComponentModel.Composition
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.ComponentModel.DataAnnotations.dll -> ../gac/System.ComponentModel.DataAnnotations/4.0.0.0__31bf3856ad364e35/System.ComponentModel.DataAnn
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.DirectoryServices.Protocols.dll -> ../gac/System.DirectoryServices.Protocols/4.0.0.0__b03f5f7f11d50a3a/System.DirectoryServices.Protoco
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.IO.Compression.FileSystem.dll -> ../gac/System.IO.Compression.FileSystem/4.0.0.0__b77a5c561934e089/System.IO.Compression.FileSystem.d
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.Reactive.Observable.Aliases.dll -> ../gac/System.Reactive.Observable.Aliases/0.0.0.0__31bf3856ad364e35/System.Reactive.Observable.Alias
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.Reactive.PlatformServices.dll -> ../gac/System.Reactive.PlatformServices/2.2.0.0__31bf3856ad364e35/System.Reactive.PlatformServices.d
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.Reactive.Runtime.Remoting.dll -> ../gac/System.Reactive.Runtime.Remoting/2.2.0.0__31bf3856ad364e35/System.Reactive.Runtime.Remoting.d
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.Reactive.Windows.Threading.dll -> ../gac/System.Reactive.Windows.Threading/2.2.0.0__31bf3856ad364e35/System.Reactive.Windows.Threading
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.Runtime.DurableInstancing.dll -> ../gac/System.Runtime.DurableInstancing/4.0.0.0__31bf3856ad364e35/System.Runtime.DurableInstancing.d
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.Runtime.Serialization.Formatters.Soap.dll -> ../gac/System.Runtime.Serialization.Formatters.Soap/4.0.0.0__b03f5f7f11d50a3a/System.Runtime.Seriali
lrwxrwxrwx 1 root root 100 Feb 6 14:53 /usr/lib/mono/4.5/System.Windows.Forms.DataVisualization.dll -> ../gac/System.Windows.Forms.DataVisualization/4.0.0.0__31bf3856ad364e35/System.Windows.Forms.DataVis
As you can see the target file name is being truncated at 100
characters.
I expanded the apk with GNU tar into a local dir & there were no broken
symlinks:
> tar --version
tar (GNU tar) 1.28
> cd foo; tar xfz ~/packages/testing/x86_64/mono-4.2.2.30-r1.apk
> find usr/lib/mono/4.5/ -xtype l
>
In archive.c, the tar header has a linkname char field which is only 100
characters long - I think this is the root cause.
*(from redmine: issue id 5076, created on 2016-02-06, closed on 2016-07-28)*
* Changesets:
* Revision 9c736d01d9647d302f9011cc1db5e6e6b99c70b7 by Timo Teräs on 2016-02-09T14:55:06Z:
```
archive: fix long symlink target names
don't overwrite the link_target if it was found from pax header.
ref #5076
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5073Priority for directory permissions2024-03-19T12:58:43ZKaarle RitvanenPriority for directory permissionsCurrently, apk uses a specific algorithm to combine the directory mode
and owner information from all installed packages. In some cases,
rendering the desired permissions in the file system requires adjusting
the APKBUILD file of all pac...Currently, apk uses a specific algorithm to combine the directory mode
and owner information from all installed packages. In some cases,
rendering the desired permissions in the file system requires adjusting
the APKBUILD file of all packages containing the directory.
The suggested solution is to allow setting a directory permission
priority on per package basis. This attribute would control which
package takes precedence in determining the permissions, similar to how
‘replaces\_priority’ affects file permissions and content. If the
highest priority would be claimed by multiple packages, apk would revert
to the current behavior, taking only the highest-priority packages into
account.
*(from redmine: issue id 5073, created on 2016-02-04)*v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/4906Documentation2020-02-25T11:38:05ZSören TempelDocumentationIt would be nice to have proper documentation for apk-tools in the form
of man pages.
The only documentation that currently exists is some articles on the
wiki and the *—help*
output.
*(from redmine: issue id 4906, created on 2015-...It would be nice to have proper documentation for apk-tools in the form
of man pages.
The only documentation that currently exists is some articles on the
wiki and the *—help*
output.
*(from redmine: issue id 4906, created on 2015-11-30)*https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/4905support for disabling cache2019-07-14T07:37:18ZNatanael Copasupport for disabling cacheIt would be nice to have an `--no-cache` option to apk so we avoid
`apk-install` wrapper scripts that only does
`apk add --update <packages> && rm -rf /var/cache/apk/*`
See
https://github.com/gliderlabs/docker-alpine/pull/18\#issuecom...It would be nice to have an `--no-cache` option to apk so we avoid
`apk-install` wrapper scripts that only does
`apk add --update <packages> && rm -rf /var/cache/apk/*`
See
https://github.com/gliderlabs/docker-alpine/pull/18\#issuecomment-107515657
*(from redmine: issue id 4905, created on 2015-11-30, closed on 2016-07-28)*
* Changesets:
* Revision c43bfed8deaa0dab47c54db9b8f374853d345a6b by Natanael Copa on 2015-12-07T12:50:32Z:
```
db: add support for --no-cache
Implement --no-cache. The index is read directly from network and not
cached. This is useful for docker, where you install a set of packages
and directly after purge the cache. (see
https://github.com/gliderlabs/docker-alpine/blob/1fc9e59d1689fc4eaf930ec66389fe58062fccec/builder/scripts/apk-install)
fixes #4905
```
* Revision 95c8dee6aadee2f1df56e0a206b1a7ab3fab6224 by Natanael Copa on 2015-12-07T13:20:22Z:
```
main/apk-tools: backport support for --no-cache
ref #4905
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/4770apk search returns duplicates2019-07-14T07:37:01ZElizabeth Myersapk search returns duplicatesapk search at present spews duplicate strings (e.g. ones already
printed), like so:
elizabethmyers:~$ apk search znc
znc-dev-1.6.1-r0
znc-modtcl-1.6.1-r0
znc-modperl-1.6.1-r0
znc-doc-1.6.1-r0
znc-dev-1.6.1-r0
znc-extra-1.6.1...apk search at present spews duplicate strings (e.g. ones already
printed), like so:
elizabethmyers:~$ apk search znc
znc-dev-1.6.1-r0
znc-modtcl-1.6.1-r0
znc-modperl-1.6.1-r0
znc-doc-1.6.1-r0
znc-dev-1.6.1-r0
znc-extra-1.6.1-r0
znc-1.6.1-r0
znc-modpython-1.6.1-r0
Note znc-dev is repeated twice. apk search should filter duplicates. I
am unsure if this happens without the testing repo; I am on edge and
have the main and testing repos enabled.
*(from redmine: issue id 4770, created on 2015-10-13, closed on 2016-07-28)*
* Changesets:
* Revision 7501f6012fc06ebfa8c6d8f928f38318267abe72 by Timo Teräs on 2015-11-09T08:06:57Z:
```
search: match packages only once
fixes #4770
apk_name_foreach_matching() can matches each package via it's
main name and all it's provides. Print matched packages only once.
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/4207/etc/apk/world can be wiped out if disk space runs out during "apk add"2019-07-14T07:35:51ZAlex Dowad/etc/apk/world can be wiped out if disk space runs out during "apk add"apk opens the /etc/apk/world file with O\_TRUNC. This means that if disk
space runs out when it tries to write the file, the previous
/etc/apk/world is lost. That means that the user can’t do an “apk del”
to free up some space.
Might it...apk opens the /etc/apk/world file with O\_TRUNC. This means that if disk
space runs out when it tries to write the file, the previous
/etc/apk/world is lost. That means that the user can’t do an “apk del”
to free up some space.
Might it be a better idea to write the new file out under a different
name, and then rename it to “/etc/apk/world”? Or is there some other way
to make this more robust?
If you would like to see this improved, I can submit a patch.
*(from redmine: issue id 4207, created on 2015-05-18, closed on 2015-12-09)*
* Uploads:
* [0001-Don-t-wipe-out-etc-apk-world-if-final-flush-to-etc-a.patch](/uploads/1b72502ca45e635876d2fcc37a35a03c/0001-Don-t-wipe-out-etc-apk-world-if-final-flush-to-etc-a.patch)Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/4064apk fails to install non-repository packages2019-07-14T07:35:32ZTed Traskapk fails to install non-repository packages- Used ‘abuild -r’ to build an application package on my edge build
box. In particular, I built freeswitch after bumping the pkgrel.
- scp’d all of the resulting freeswitch packages to another edge box
for testing.
- ran ‘a...- Used ‘abuild -r’ to build an application package on my edge build
box. In particular, I built freeswitch after bumping the pkgrel.
- scp’d all of the resulting freeswitch packages to another edge box
for testing.
- ran ‘apk add -f —allow-untrusted /tmp/freeswitch-1.4.18-r2.apk’, and
nothing happened. I see no error or success messages, just the
normal OK message.
I do not have package caching enabled, therefore the need for ‘-f’. The
new package (freeswitch><Q1cL6NhQwgE7IPZRLhO4bePmdvyWo=) is added
to /etc/apk/world, but none of the files are installed. I verified that
the package contains the proper files using tar. Any subsequent calls
into apk (besides apk del freeswitch) result in ERROR: unsatisfiable
constraints.
*(from redmine: issue id 4064, created on 2015-04-13, closed on 2015-06-01)*Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/3493apk won't install package from pinned repo2019-07-14T07:34:17ZJohannes Matheisapk won't install package from pinned repoI need gcc 4.8.3 due to an incompatibility with 4.8.2. The new version
is available @edge:
% sudo apk update
fetch
http://dl-3.alpinelinux.org/alpine/v3.0/main/x86\_64/APKINDEX.tar.gz
fetch
http://dl-3.alpinelinux.org/alpine/edge/ma...I need gcc 4.8.3 due to an incompatibility with 4.8.2. The new version
is available @edge:
% sudo apk update
fetch
http://dl-3.alpinelinux.org/alpine/v3.0/main/x86\_64/APKINDEX.tar.gz
fetch
http://dl-3.alpinelinux.org/alpine/edge/main/x86\_64/APKINDEX.tar.gz
fetch
http://dl-3.alpinelinux.org/alpine/edge/testing/x86\_64/APKINDEX.tar.gz
v3.0.6-2-g32163f4 \[http://dl-3.alpinelinux.org/alpine/v3.0/main\]
testing \[/home/jomat/packages/testing/\]
v141022-275-gef56c18 \[http://dl-3.alpinelinux.org/alpine/edge/main\]
v141022-275-gef56c18
\[http://dl-3.alpinelinux.org/alpine/edge/testing\]
OK: 11279 distinct packages available
% apk policy gcc
gcc policy:
4.8.2-r10:
lib/apk/db/installed
etc/apk/cache
http://dl-3.alpinelinux.org/alpine/v3.0/main
4.8.3-r0:
@edge http://dl-3.alpinelinux.org/alpine/edge/main
%
I can’t install it with any of those steps:
% sudo apk -v add gcc@edge
OK: 591 packages, 4764 dirs, 65353 files, 1649 MiB
% sudo apk -v add -u gcc@edge
OK: 591 packages, 4764 dirs, 65353 files, 1649 MiB
% sudo apk add gcc@edge>=4.8.3 |wc -l
0
% sudo apk upgrade —latest
OK: 1649 MiB in 591 packages
%
% sudo apk version gcc
Installed: Available:
gcc-4.8.2-r10 = 4.8.2-r10
%
Attached is my /etc/apk/world where apk already added gcc@edge.
apk —version: apk-tools 2.4.4, compiled for x86\_64.
*(from redmine: issue id 3493, created on 2014-10-29, closed on 2019-06-11)*
* Uploads:
* [world](/uploads/998f44d7bfd54b71b406873fe03583cb/world)https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/3371apk version -U segfaults when running as non-root2019-07-14T07:34:00ZNatanael Copaapk version -U segfaults when running as non-root$ apk version -U
fetch http://nl.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
Segmentation fault
*(from redmine: issue id 3371, created on 2014-09-18, closed on 2014-11-18)*
* Changesets:
* Revision 5496560a4fa8fe...$ apk version -U
fetch http://nl.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
Segmentation fault
*(from redmine: issue id 3371, created on 2014-09-18, closed on 2014-11-18)*
* Changesets:
* Revision 5496560a4fa8fee3f3e60c2092f413f4aa76c088 by Timo Teräs on 2014-10-07T16:05:06Z:
```
db: fix crash if unable to download cache item
fixes #3371
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/3027Support for xattr2019-07-14T07:33:16ZNatanael CopaSupport for xattrWe need add support for xattr in apk.
We need it for avoid suid root for ‘ping’: \#3000.
And will will likely need to migrate our pax marking to xattr:
https://wiki.gentoo.org/wiki/Hardened/PaX\_flag\_migration\_from\_PT\_PAX\_to\_XATT...We need add support for xattr in apk.
We need it for avoid suid root for ‘ping’: \#3000.
And will will likely need to migrate our pax marking to xattr:
https://wiki.gentoo.org/wiki/Hardened/PaX\_flag\_migration\_from\_PT\_PAX\_to\_XATTR\_PAX
This also means we need to add support for xattr in busybox tar.
*(from redmine: issue id 3027, created on 2014-06-12, closed on 2015-05-26)*
* Relations:
* blocks #3280
* Changesets:
* Revision be8e133c0b5ba0980d0debbf26b76a0b866689e7 by Timo Teräs on 2015-03-10T13:38:06Z:
```
extract xattrs from packages
ref #3027
```
* Revision 8d1ec4c5bc031da9e2441a63df965757d74d5c33 by Timo Teräs on 2015-03-11T15:10:33Z:
```
calculate and store checksum of xattrs
ref #3027
```
* Revision 83ab02230115eab725bf92f111f4a3f2a41db5b1 by Timo Teräs on 2015-04-08T07:27:49Z:
```
audit xattrs
ref #3027
```Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/2966Alpine permission bug with lbu/apk-tools2019-07-14T07:33:08ZNicolas SchmerberAlpine permission bug with lbu/apk-toolsHi,
As discussed on the mailing list this is a bug report for the permission
in /etc.
Description :
I’m using the lastest stable 2.7.8 ALpineLinux on embeded hardware
(like
soekris).
On only use Alpine in ram and all is commited ...Hi,
As discussed on the mailing list this is a bug report for the permission
in /etc.
Description :
I’m using the lastest stable 2.7.8 ALpineLinux on embeded hardware
(like
soekris).
On only use Alpine in ram and all is commited to a compact flash, like
in a normal router.
I’m a little confused to ask that but it seems i found something which
looks like a bug.
I installed the bind DNS server package, the perms are in /etc :
drwxr-x—- 2 root named 620 May 23 2014 bind
Now for a reason i need to have data sync into that dir i then change
the perms : to 775 mode , and of course lbu commit
After reboot the perms are again as installed.
I then tried to switch the
owner:group ->same
I tried to force a lbu add /etc/bind ->same problem.
I believe it can be done with every directory from a package in /etc.
Answer from Natanael :
I think its apk-tools that “fixes” the permissions on the dirs when it
install the files.
Answer from Timo :
Please file a bug. The permissions on overlay should override package
ones.
We have even code to include stuff in overlay if the only change is in
permissions. This probably is regression caused by the code “merging”
the directory permissions from different packages.
Regards
*(from redmine: issue id 2966, created on 2014-05-24, closed on 2015-12-09)*
* Relations:
* relates #9364
* Changesets:
* Revision 09e48d8f06bfb924b80ce3e95c281524c4891828 by Timo Teräs on 2014-10-07T13:11:29Z:
```
db: rework directory permission handling
Apk used to reset directory permissions always, but this is undesirable
if user has modified the permissions - especially during tmpfs boot.
Though, it is desirable to update the permissions when packaging has
changed permissions, or a new package is installed and the merged
permission mask / owner changes.
Thus the new code updates the permissions only if:
1) We are booting and directory is not in apkovl
2) The directory is modified by a package install/remove/upgrade
3) The filesystem directory permission matched database
Additionally "apk fix --directory-permissions" can be used to reset
all directory permissions to the database defaults.
Fixes #2966
```Timo TeräsTimo Teräs