apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2022-12-21T20:00:36Zhttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/5056Repeated fields in apk info with multiple repositories2022-12-21T20:00:36ZMark WhiteRepeated fields in apk info with multiple repositories`apk info` repeats some fields when multiple repositories are in use.
For example, with a clean Alpine 3.3.1, set /etc/apk/repositories to:
http://dl-1.alpinelinux.org/alpine/v3.3/main
@edge http://dl-1.alpinelinux.org/alpine/ed...`apk info` repeats some fields when multiple repositories are in use.
For example, with a clean Alpine 3.3.1, set /etc/apk/repositories to:
http://dl-1.alpinelinux.org/alpine/v3.3/main
@edge http://dl-1.alpinelinux.org/alpine/edge/main
Running `apk update && apk info vim` produces:
vim-7.4.943-r2 description:
advanced text editor
vim-7.4.943-r2 webpage:
http://www.vim.org
vim-7.4.943-r2 installed size:
25038848
vim-7.4.943-r2 description:
advanced text editor
vim-7.4.943-r2 webpage:
http://www.vim.org
vim-7.4.943-r2 installed size:
25038848
With `apk info -a` on an installed package, not all fields are repeated;
eg “contains” is only printed once, but “description” is repeated.
*(from redmine: issue id 5056, created on 2016-01-31)*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/5980Ability to Default to --no-cache2019-12-27T14:52:15ZNoah NordrumAbility to Default to --no-cacheGiven that
docker --no-cache add curl
would be best practice in a docker container (I assume), it would be
nice if there was a mechanism to change that default.
I can think of a number of ways:
- compile flag
- separate ap...Given that
docker --no-cache add curl
would be best practice in a docker container (I assume), it would be
nice if there was a mechanism to change that default.
I can think of a number of ways:
- compile flag
- separate apk-tools package
- /etc/apkrc
- environment variable that is always added to the command line like
APK\_OPTIONS that could be set to —no-cache in the alpine base image
or you could just tell me to keep using in my root container :)
alias apk="apk --no-cache"
I know it seems I’m being super lazy, but I think it’s best to provide
best practices as the default options and then let people deviate if
they choose.
*(from redmine: issue id 5980, created on 2016-07-28)*
* Relations:
* relates #8161v3.0Timo 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/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/7101Allow apk to operate on .apk FILE most places PACKAGE is specified2022-12-21T20:00:36ZChris GiorgiAllow apk to operate on .apk FILE most places PACKAGE is specifiedCurrently, apk only allows package names where PACKAGE is accepted by
the various tools (see Issue 7100 for request for full atoms).
In most cases, it would also make sense to operate on a .apk FILE in the
same manner.
For instance,
...Currently, apk only allows package names where PACKAGE is accepted by
the various tools (see Issue 7100 for request for full atoms).
In most cases, it would also make sense to operate on a .apk FILE in the
same manner.
For instance,
apk info -L /tmp/linux-grsec-4.9.20-r0.apk
-or-
apk fix -i ./my-wip-package-0.11-r0.apk
*(from redmine: issue id 7101, created on 2017-04-07)*v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/7102Information available via 'apk info' on a package is incomplete with respect ...2022-12-21T20:00:36ZChris GiorgiInformation available via 'apk info' on a package is incomplete with respect to contents of .PKGINFO.Currently ‘apk info’ can not retrieve all information of interest on a
package, especially once Issue \#7101 is implemented.
‘apk info’ (or perhaps a more direct ‘apk query’) should be able to
extract any information stored in a .apk f...Currently ‘apk info’ can not retrieve all information of interest on a
package, especially once Issue \#7101 is implemented.
‘apk info’ (or perhaps a more direct ‘apk query’) should be able to
extract any information stored in a .apk file in raw or slightly cooked
form suitable for use in scripts.
*(from redmine: issue id 7102, created on 2017-04-07)*v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/8752Add support for listing all (reverse) dependencies of the specified package r...2022-12-21T20:00:36ZJakub JirutkaAdd support for listing all (reverse) dependencies of the specified package recursively*(from redmine: issue id 8752, created on 2018-03-30)**(from redmine: issue id 8752, created on 2018-03-30)*v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/9411apk upgrade bug when new directory has same name as old file2022-12-21T18:50:52ZNatanael Copaapk upgrade bug when new directory has same name as old fileI got errors when upgrading gimp with apk-tools-2.10.1, with the files
under `usr/lib/gimp/2.0/plug-ins`.
To reproduce:
$ docker run --rm -it alpine:3.8 sh -c "apk add -U gimp && sed -i -e 's/v3.8/edge/' /etc/apk/repositories && ap...I got errors when upgrading gimp with apk-tools-2.10.1, with the files
under `usr/lib/gimp/2.0/plug-ins`.
To reproduce:
$ docker run --rm -it alpine:3.8 sh -c "apk add -U gimp && sed -i -e 's/v3.8/edge/' /etc/apk/repositories && apk upgrade -U -a"
...
(82/88) Replacing poppler-glib (0.56.0-r1 -> 0.56.0-r1)
(83/88) Upgrading gimp (2.8.22-r2 -> 2.10.6-r0)
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-header/.apk.a363331e9a8d3d487a216eda7ca2ffea8196714a3c49a26e to usr/lib/gimp/2.0/plug-ins/file-header/file-header.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/cartoon/.apk.8dcf9daeda099f7d5746b6ea69b304dac6a3d7e7ac42f120 to usr/lib/gimp/2.0/plug-ins/cartoon/cartoon.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/gimpressionist/.apk.9ea15f5626abef4a2a6a67e53cc297193fcdaef84cbe5750 to usr/lib/gimp/2.0/plug-ins/gimpressionist/gimpressionist.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/sharpen/.apk.c68da8a90a2326b2e799dfdf80b509892110e257957059bd to usr/lib/gimp/2.0/plug-ins/sharpen/sharpen.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-faxg3/.apk.42666728d028e8c6bc83b57e93c05c051bb8bd249aa2a685 to usr/lib/gimp/2.0/plug-ins/file-faxg3/file-faxg3.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-gif-save/.apk.f350657ed077ff3e5f5f6fbdef0cef481c6d111267aef3e2 to usr/lib/gimp/2.0/plug-ins/file-gif-save/file-gif-save.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/filter-pack/.apk.19bd28a0c8acbc1ca0f3c13052d7d5016ec6ab15f2964f32 to usr/lib/gimp/2.0/plug-ins/filter-pack/filter-pack.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/contrast-normalize/.apk.3cc77b48ef05a1c1d6be60018735d57ba0919679a34e4106 to usr/lib/gimp/2.0/plug-ins/contrast-normalize/contrast-normalize.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-csource/.apk.1a5688fd9666d688975512796e0c2ca168ce7838dc142b43 to usr/lib/gimp/2.0/plug-ins/file-csource/file-csource.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/gradient-map/.apk.c92c29787c5e0b0c64780576904f6ea67d3a95044bc6aad8 to usr/lib/gimp/2.0/plug-ins/gradient-map/gradient-map.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-pnm/.apk.da385ea537cc77a8f056db03d7e8f9bf5ee3b87acdfbba31 to usr/lib/gimp/2.0/plug-ins/file-pnm/file-pnm.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/qbist/.apk.2d44115674ae5e18db2072f77332276dc744c863d8321182 to usr/lib/gimp/2.0/plug-ins/qbist/qbist.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-psp/.apk.96d194c77174ec9bcf24a8763081ef86de20addac1b7f9f9 to usr/lib/gimp/2.0/plug-ins/file-psp/file-psp.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/map-object/.apk.060024a44385cc536458349a0cb88d755dc3f2a706125a5a to usr/lib/gimp/2.0/plug-ins/map-object/map-object.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-pcx/.apk.a05d12d5218565d31b8fa984794015a30f254eb10c783dd8 to usr/lib/gimp/2.0/plug-ins/file-pcx/file-pcx.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/gradient-flare/.apk.a9ece2fc03b249a268f09077e0dbaccb2c7bb7482c2e5edc to usr/lib/gimp/2.0/plug-ins/gradient-flare/gradient-flare.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/script-fu/.apk.0f0b53459fd53783f077d58820b3f644eae66259593d3df2 to usr/lib/gimp/2.0/plug-ins/script-fu/script-fu.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/emboss/.apk.81b74c54211133928823931613a830017938ae56b77a6a59 to usr/lib/gimp/2.0/plug-ins/emboss/emboss.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/smooth-palette/.apk.d12b219194efd3fbf17179db5d4f02299d8b6a741e6d801c to usr/lib/gimp/2.0/plug-ins/smooth-palette/smooth-palette.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-compressor/.apk.712b2bb8e13017ead0a1230b2c79eba0661dc295d0743fab to usr/lib/gimp/2.0/plug-ins/file-compressor/file-compressor.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/screenshot/.apk.dcd62f978b4361ba4c2d99a3acff953afbcc41bfb4b8f8e1 to usr/lib/gimp/2.0/plug-ins/screenshot/screenshot.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/film/.apk.a0e0c11ada421ccdf8ccdb276905447e6531bf396dd098de to usr/lib/gimp/2.0/plug-ins/film/film.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-pat/.apk.47363645cdc96944dbe7948f13f462dcf44ef9d71c702442 to usr/lib/gimp/2.0/plug-ins/file-pat/file-pat.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/tile-small/.apk.7cdd630207ea1b00ed6a78e5e2655d1870054b58b9c3411f to usr/lib/gimp/2.0/plug-ins/tile-small/tile-small.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/selection-to-path/.apk.8870205db954bc2529300d75c87b0fe8d10ea6b1d7669241 to usr/lib/gimp/2.0/plug-ins/selection-to-path/selection-to-path.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-svg/.apk.274ff0529815d883ee31129117e85e9124db04c52cbf9979 to usr/lib/gimp/2.0/plug-ins/file-svg/file-svg.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/tile/.apk.2481d1c9c205ac690f4af65ed76d09608a1bab28c1cda2ae to usr/lib/gimp/2.0/plug-ins/tile/tile.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/sample-colorize/.apk.cb37ae4ebc732a4f467a6dbc0cf3916c7927339ccc8b0a76 to usr/lib/gimp/2.0/plug-ins/sample-colorize/sample-colorize.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-pdf-save/.apk.1e3e2c5adbc33e4809d3cb6bbfc95448f8c969daa1c6a999 to usr/lib/gimp/2.0/plug-ins/file-pdf-save/file-pdf-save.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/warp/.apk.1ed4316bc2a3d290c2b6109e65ef8d7a8f6d588b6d31b40f to usr/lib/gimp/2.0/plug-ins/warp/warp.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/flame/.apk.018f909206e515c6c03ab18ee2b55cebb87c17abafd3c0a6 to usr/lib/gimp/2.0/plug-ins/flame/flame.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/pagecurl/.apk.fe367a655cc815040911a9b0878d760398562c8db61d645f to usr/lib/gimp/2.0/plug-ins/pagecurl/pagecurl.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/destripe/.apk.73710619d5a77ddc84c1e04c48478199b808a9a8460c9863 to usr/lib/gimp/2.0/plug-ins/destripe/destripe.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/edge-neon/.apk.626332d27ef264d2170369db4b330e5d073091decb2026ff to usr/lib/gimp/2.0/plug-ins/edge-neon/edge-neon.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/guillotine/.apk.5a69a4851870aaa957a909170789cf8632bb00b46d90a555 to usr/lib/gimp/2.0/plug-ins/guillotine/guillotine.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/curve-bend/.apk.77b778320e7b0965562aad17e954d06f35c317bd762c9dfc to usr/lib/gimp/2.0/plug-ins/curve-bend/curve-bend.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/color-cube-analyze/.apk.3cddc3845c39cd10dd3cf6188ae2b8ee8c62a6d7f9e7d9b0 to usr/lib/gimp/2.0/plug-ins/color-cube-analyze/color-cube-analyze.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/newsprint/.apk.ecc9d35c6c427415bcd0eca6d2401d49d2aeebe44548f3c4 to usr/lib/gimp/2.0/plug-ins/newsprint/newsprint.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/colormap-remap/.apk.3b81d43aab2cfedf5f8ec5d0f5179d90c97d2bbd5484a8eb to usr/lib/gimp/2.0/plug-ins/colormap-remap/colormap-remap.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/ifs-compose/.apk.8e6f432a16e4ef717c74d91165d8eabb76f02de582c44a6c to usr/lib/gimp/2.0/plug-ins/ifs-compose/ifs-compose.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/fractal-explorer/.apk.a5fa4cf4b74c1c1f5f634873f45f8abaa376e7fdb66157af to usr/lib/gimp/2.0/plug-ins/fractal-explorer/fractal-explorer.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/animation-optimize/.apk.f57621e36520b9d18fb48e6ff09356c79b1ca8991fb553e6 to usr/lib/gimp/2.0/plug-ins/animation-optimize/animation-optimize.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-dicom/.apk.f822fe7ec3eb63baa723c532412a1f47ccb0c8a3be9a740e to usr/lib/gimp/2.0/plug-ins/file-dicom/file-dicom.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/imagemap/.apk.42ec92293ce24e7e9565337971cae2c35e38ae28329d0f5c to usr/lib/gimp/2.0/plug-ins/imagemap/imagemap.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-gbr/.apk.3070e9c4d4a62481cb62ab191518548de2d7826195ca887e to usr/lib/gimp/2.0/plug-ins/file-gbr/file-gbr.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/plugin-browser/.apk.0fc321725e22632be24187b3cd09c66fcd800c992661303e to usr/lib/gimp/2.0/plug-ins/plugin-browser/plugin-browser.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/lighting/.apk.5d64532a0dd512b3f1b14b02640284f453cb2788298b2b9f to usr/lib/gimp/2.0/plug-ins/lighting/lighting.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-tga/.apk.90bbe438af2daa64a11360b237bfef7286ac39e4c88883a4 to usr/lib/gimp/2.0/plug-ins/file-tga/file-tga.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/depth-merge/.apk.517c875769452f2f4d2bb5518770a3fe710666f3e863a255 to usr/lib/gimp/2.0/plug-ins/depth-merge/depth-merge.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/oilify/.apk.a3458585fa37f8a363bcef91bfd2d53230bfdc289ba81719 to usr/lib/gimp/2.0/plug-ins/oilify/oilify.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-desktop-link/.apk.c7f1000a1e308a6006dda1c346153c9d4fcb056dfb765dde to usr/lib/gimp/2.0/plug-ins/file-desktop-link/file-desktop-link.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-ico/.apk.fb7c787c432ed090b3073e361399ac3b4b7237a80ff4e358 to usr/lib/gimp/2.0/plug-ins/file-ico/file-ico.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/hot/.apk.7388308df4b175391ba26fe626ef7a87fafa148191985110 to usr/lib/gimp/2.0/plug-ins/hot/hot.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-html-table/.apk.9c66606ea318ca825c13d5e5ad0911fbd5a52e770ba90072 to usr/lib/gimp/2.0/plug-ins/file-html-table/file-html-table.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/cml-explorer/.apk.25383b5193a80d59b8c6726ec11be51826d2d1671e08a9f4 to usr/lib/gimp/2.0/plug-ins/cml-explorer/cml-explorer.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-xbm/.apk.42e9b4cbea2d3e7d1c11f852938eb77765d0c73db8eca816 to usr/lib/gimp/2.0/plug-ins/file-xbm/file-xbm.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/web-browser/.apk.6e38e4f9c9dbc4a9d430fda8be2e709a9f91156570a0c4d0 to usr/lib/gimp/2.0/plug-ins/web-browser/web-browser.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/sphere-designer/.apk.86023409904ad3e64b8d003f2cc38eaa6d18aef7d0e9c18e to usr/lib/gimp/2.0/plug-ins/sphere-designer/sphere-designer.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/procedure-browser/.apk.9a89db987f5c20496be9a9872df4c8455a7c41544c8fc57a to usr/lib/gimp/2.0/plug-ins/procedure-browser/procedure-browser.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/grid/.apk.74a2cc6fafc470e6786380e8b1b4b2d8950919fc23aaa3f5 to usr/lib/gimp/2.0/plug-ins/grid/grid.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-fli/.apk.0fd710f850d7a310e088caaa9d08505863c9ec230d711424 to usr/lib/gimp/2.0/plug-ins/file-fli/file-fli.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/unit-editor/.apk.e5d820196ba240fa83d7cce0047ed1305785a22c247a6dd5 to usr/lib/gimp/2.0/plug-ins/unit-editor/unit-editor.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/softglow/.apk.91167a155c9933f0e4aedf27e0c6b974809415a9c60f4516 to usr/lib/gimp/2.0/plug-ins/softglow/softglow.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/despeckle/.apk.ed70b470515299e8ae39dfbd6d72b57f1e1ebe09909ef274 to usr/lib/gimp/2.0/plug-ins/despeckle/despeckle.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-xwd/.apk.bc8fdaed8058e1f1cf5833f78cf5dba353e1795a68753084 to usr/lib/gimp/2.0/plug-ins/file-xwd/file-xwd.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-pdf-load/.apk.a1bbc17098409b6d56a841ad2fe94e09a4dde1afae17cb28 to usr/lib/gimp/2.0/plug-ins/file-pdf-load/file-pdf-load.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-glob/.apk.60556d363bee6c856fda408a2454f9bcdad9a52a793cd1ec to usr/lib/gimp/2.0/plug-ins/file-glob/file-glob.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-bmp/.apk.f897538451de918519ebf6187f3358bd16feab23001e46c2 to usr/lib/gimp/2.0/plug-ins/file-bmp/file-bmp.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-gih/.apk.bb41af42f2ca7356fbe83cdf6ffaa4c4252248705b1be91d to usr/lib/gimp/2.0/plug-ins/file-gih/file-gih.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/photocopy/.apk.5586512848e70cd732ecaf00a9069af271d827ee0b9c280a to usr/lib/gimp/2.0/plug-ins/photocopy/photocopy.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/crop-zealous/.apk.e7805ff991563d37283c12a2a6db21232b9e053b8b766812 to usr/lib/gimp/2.0/plug-ins/crop-zealous/crop-zealous.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-sgi/.apk.f48589133f0bed404559b43509b1f034c980b502e6906f04 to usr/lib/gimp/2.0/plug-ins/file-sgi/file-sgi.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/contrast-retinex/.apk.eb05f1d0ab61c9a6959ba635cc05bab6ef91b12474dff8ca to usr/lib/gimp/2.0/plug-ins/contrast-retinex/contrast-retinex.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/help/.apk.217a52b85ce1ffb20e2145fcbd87e9ca15e6431859abc6be to usr/lib/gimp/2.0/plug-ins/help/help.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/van-gogh-lic/.apk.63c8dae6ecc64d4018af721f3a1bfc4c42e726836db3147c to usr/lib/gimp/2.0/plug-ins/van-gogh-lic/van-gogh-lic.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/animation-play/.apk.ee745abc5cd699763e71daa066a03fb6566916baea0c4928 to usr/lib/gimp/2.0/plug-ins/animation-play/animation-play.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/compose/.apk.df40f7a00d23674f958317f55a21cd5db491dc8661791633 to usr/lib/gimp/2.0/plug-ins/compose/compose.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-sunras/.apk.ebaa491a7f633b7e32d2da8d5714b0b68cc03cf8839471a7 to usr/lib/gimp/2.0/plug-ins/file-sunras/file-sunras.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/align-layers/.apk.bded1e067b5fb454dd83180ad05d6e48033dc4a5e7382f4c to usr/lib/gimp/2.0/plug-ins/align-layers/align-layers.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/colorify/.apk.d6f4c38313957cd555e1310440b7058a0a291af0a09b3837 to usr/lib/gimp/2.0/plug-ins/colorify/colorify.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/border-average/.apk.35eda6fda6f14f60f0e2c16fa29c66a595e4bc03badb4e73 to usr/lib/gimp/2.0/plug-ins/border-average/border-average.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-gif-load/.apk.41ef8db83fe41062b1e5ad23ff5d982e41a4a7bc405158b0 to usr/lib/gimp/2.0/plug-ins/file-gif-load/file-gif-load.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/nl-filter/.apk.54f7ca14d633e3224ce2aa618174d9ba0b9872bc2fe0f5f0 to usr/lib/gimp/2.0/plug-ins/nl-filter/nl-filter.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/checkerboard/.apk.3a50f870113c8484845a0661aa783615de571c9524ba441e to usr/lib/gimp/2.0/plug-ins/checkerboard/checkerboard.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/fractal-trace/.apk.acf45a25e00c8cba60c803e562df6ba6bb59ad5bbfd9fa78 to usr/lib/gimp/2.0/plug-ins/fractal-trace/fractal-trace.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/blur/.apk.984d792fb634be2733c119411cecdc0f9f83fc94afb1eb25 to usr/lib/gimp/2.0/plug-ins/blur/blur.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-jpeg/.apk.211616660069a33ae3fbd9c30a3590917c376215af18aade to usr/lib/gimp/2.0/plug-ins/file-jpeg/file-jpeg.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/mail/.apk.5bbc640cffa9a1aaa8ff03218ee042e377ef61621d05ab3b to usr/lib/gimp/2.0/plug-ins/mail/mail.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/gfig/.apk.8db205ad8adf2ff166694787c2c340e48cd8a2d9a19af9dc to usr/lib/gimp/2.0/plug-ins/gfig/gfig.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/print/.apk.fa7c0975c03c111bb3f233203c2da629bc2997b73c717803 to usr/lib/gimp/2.0/plug-ins/print/print.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/decompose/.apk.373c8a4737ac1d88b6704adf6f398dc7c574d572c0ad4258 to usr/lib/gimp/2.0/plug-ins/decompose/decompose.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-png/.apk.c77178418a2eff5a991d14bb5491b3ac6b7f6308dde8edda to usr/lib/gimp/2.0/plug-ins/file-png/file-png.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-cel/.apk.ee901d8d19ceb0e383f76f43df87db9a6060bcd0389949d8 to usr/lib/gimp/2.0/plug-ins/file-cel/file-cel.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-pix/.apk.fde6e2faff38240b50992916ce7a1077743ad896dcb30fdf to usr/lib/gimp/2.0/plug-ins/file-pix/file-pix.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-xpm/.apk.d3319869d1e74dd094739a92df199005218c00377a739707 to usr/lib/gimp/2.0/plug-ins/file-xpm/file-xpm.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/jigsaw/.apk.c8bac5d35f5a569d7d8ab85ffd54d38e761d18560e1ae377 to usr/lib/gimp/2.0/plug-ins/jigsaw/jigsaw.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/edge-dog/.apk.d284217513dcf3a0ba2dbd9ecdda7c6a2c88a583bc39810d to usr/lib/gimp/2.0/plug-ins/edge-dog/edge-dog.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/sparkle/.apk.9b473cbbfb73770427a898a57dc138fb9133deeaa618f73d to usr/lib/gimp/2.0/plug-ins/sparkle/sparkle.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/blinds/.apk.fbf81c5682b52909f375c49f39d36b586a5dab9b20524401 to usr/lib/gimp/2.0/plug-ins/blinds/blinds.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-fits/.apk.223f4f8b9e5ebd2e4b706882c440718ab2fcb8d45854466a to usr/lib/gimp/2.0/plug-ins/file-fits/file-fits.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/max-rgb/.apk.355ca91bd712d0f651b8d74ea7e8ca061f527608c30dc984 to usr/lib/gimp/2.0/plug-ins/max-rgb/max-rgb.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/color-enhance/.apk.4a3959c7b74297529f27d41c4b625073ad62c57b44edb3fa to usr/lib/gimp/2.0/plug-ins/color-enhance/color-enhance.
(84/88) Replacing scanelf (1.2.3-r0 -> 1.2.3-r0)
...
It also fails when I try to apk fix it, apparently due to last directory
in path is missing:
$ sudo apk fix
[sudo] password for ncopa:
(1/1) Reinstalling gimp (2.10.6-r0)
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-header/file-header: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/cartoon/cartoon: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/gimpressionist/gimpressionist: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/sharpen/sharpen: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/metadata-editor/metadata-editor: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/goat-exercise/goat-exercise: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-faxg3/file-faxg3: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-gif-save/file-gif-save: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/filter-pack/filter-pack: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/contrast-normalize/contrast-normalize: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-rawtherapee/file-rawtherapee: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-raw-data/file-raw-data: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-csource/file-csource: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/gradient-map/gradient-map: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-pnm/file-pnm: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/qbist/qbist: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-psp/file-psp: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/map-object/map-object: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-pcx/file-pcx: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/gradient-flare/gradient-flare: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/script-fu/script-fu: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/emboss/emboss: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/smooth-palette/smooth-palette: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-compressor/file-compressor: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/screenshot/screenshot: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/film/film: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-pat/file-pat: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/tile-small/tile-small: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/selection-to-path/selection-to-path: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-svg/file-svg: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/tile/tile: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/sample-colorize/sample-colorize: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-pdf-save/file-pdf-save: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/warp/warp: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/flame/flame: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/pagecurl/pagecurl: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/destripe/destripe: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/edge-neon/edge-neon: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/guillotine/guillotine: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/curve-bend/curve-bend: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-darktable/file-darktable: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/color-cube-analyze/color-cube-analyze: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/newsprint/newsprint: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/colormap-remap/colormap-remap: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/wavelet-decompose/wavelet-decompose: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/ifs-compose/ifs-compose: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/fractal-explorer/fractal-explorer: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-raw-placeholder/file-raw-placeholder: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/animation-optimize/animation-optimize: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-dicom/file-dicom: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/imagemap/imagemap: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/metadata-viewer/metadata-viewer: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-gbr/file-gbr: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/plugin-browser/plugin-browser: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/lighting/lighting: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-tga/file-tga: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/depth-merge/depth-merge: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/oilify/oilify: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-desktop-link/file-desktop-link: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-ico/file-ico: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/hot/hot: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-html-table/file-html-table: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/cml-explorer/cml-explorer: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-xbm/file-xbm: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/web-browser/web-browser: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/sphere-designer/sphere-designer: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/procedure-browser/procedure-browser: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/grid/grid: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/busy-dialog/busy-dialog: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-fli/file-fli: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/unit-editor/unit-editor: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/softglow/softglow: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/despeckle/despeckle: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-xwd/file-xwd: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-pdf-load/file-pdf-load: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-glob/file-glob: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-bmp/file-bmp: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-gih/file-gih: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/photocopy/photocopy: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/crop-zealous/crop-zealous: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-sgi/file-sgi: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/contrast-retinex/contrast-retinex: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-gegl/file-gegl: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/help/help: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/van-gogh-lic/van-gogh-lic: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/animation-play/animation-play: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/compose/compose: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-sunras/file-sunras: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/align-layers/align-layers: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/colorify/colorify: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/border-average/border-average: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-gif-load/file-gif-load: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/nl-filter/nl-filter: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/checkerboard/checkerboard: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/fractal-trace/fractal-trace: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/blur/blur: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-jpeg/file-jpeg: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/mail/mail: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/gfig/gfig: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-tiff/file-tiff: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/print/print: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-psd/file-psd: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/decompose/decompose: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-png/file-png: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-cel/file-cel: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-pix/file-pix: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-xpm/file-xpm: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/jigsaw/jigsaw: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/edge-dog/edge-dog: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/sparkle/sparkle: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/blinds/blinds: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/file-fits/file-fits: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/max-rgb/max-rgb: No such file or directory
ERROR: Failed to create usr/lib/gimp/2.0/plug-ins/color-enhance/color-enhance: No such file or directory
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/file-header/.apk.a363331e9a8d3d487a216eda7ca2ffea8196714a3c49a26e to usr/lib/gimp/2.0/plug-ins/file-header/file-header.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/cartoon/.apk.8dcf9daeda099f7d5746b6ea69b304dac6a3d7e7ac42f120 to usr/lib/gimp/2.0/plug-ins/cartoon/cartoon.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/gimpressionist/.apk.9ea15f5626abef4a2a6a67e53cc297193fcdaef84cbe5750 to usr/lib/gimp/2.0/plug-ins/gimpressionist/gimpressionist.
ERROR: gimp-2.10.6-r0: failed to rename usr/lib/gimp/2.0/plug-ins/sharpen/.apk.c68da8a90a2326b2e799dfdf80b509892110e257957059bd to usr/lib/gimp/2.0/plug-ins/sharpen/sharpen.
...
When I look at the strace, it seems like openat() fails to create the
tempfile:
...
unlinkat(3, "usr/lib/gimp/2.0/plug-ins/file-header/.apk.a363331e9a8d3d487a216eda7ca2ffea8196714a3c49a26e", 0) = -1 ENOENT (No such file or dire
ctory)
openat(3, "usr/lib/gimp/2.0/plug-ins/file-header/.apk.a363331e9a8d3d487a216eda7ca2ffea8196714a3c49a26e", O_RDWR|O_CREAT|O_EXCL|O_TRUNC|O_CLOEXE
C, 0755) = -1 ENOENT (No such file or directory)
writev(2, [{iov_base="", iov_len=0}, {iov_base="ERROR: ", iov_len=7}], 2ERROR: ) = 7
writev(2, [{iov_base="Failed to create usr/lib/gimp/2."..., iov_len=68}, {iov_base="No such file or directory", iov_len=25}], 2Failed to create usr/lib/gimp/2.0/plug-ins/file-header/file-header: No such file or directory) = 93
writev(2, [{iov_base="", iov_len=0}, {iov_base=NULL, iov_len=0}], 2) = 0
writev(2, [{iov_base="", iov_len=0}, {iov_base="\n", iov_len=1}], 2
) = 1
...
*(from redmine: issue id 9411, created on 2018-09-11)*v3.1Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10651APK should have --force-reinstall option2022-12-21T20:00:36ZAndrey LAPK should have --force-reinstall optionHello!
Sometimes it’s needed to reinstall package overwriting all files
included in package
There should an easy way to do it.
*(from redmine: issue id 10303, created on 2019-04-19)*Hello!
Sometimes it’s needed to reinstall package overwriting all files
included in package
There should an easy way to do it.
*(from redmine: issue id 10303, created on 2019-04-19)*v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10653"apk info" output could be a lot nicer looking2024-03-22T13:03:31ZLuca Weiss"apk info" output could be a lot nicer lookingEspecially when multiple versions of the same package are available, the output is really hard to read:
```
$ apk info mesa-dev
mesa-dev-9999-r8 description:
[c41545c2f523e9f29e94317d5378045618ba6f67] Mesa DRI OpenGL library (development...Especially when multiple versions of the same package are available, the output is really hard to read:
```
$ apk info mesa-dev
mesa-dev-9999-r8 description:
[c41545c2f523e9f29e94317d5378045618ba6f67] Mesa DRI OpenGL library (development files)
mesa-dev-9999-r8 webpage:
https://www.mesa3d.org
mesa-dev-9999-r8 installed size:
2609152
mesa-dev-9999-r7 description:
[19.1.0] Mesa DRI OpenGL library (development files)
mesa-dev-9999-r7 webpage:
https://www.mesa3d.org
mesa-dev-9999-r7 installed size:
2576384
mesa-dev-19.1.2-r1 description:
Mesa DRI OpenGL library (development files)
mesa-dev-19.1.2-r1 webpage:
https://www.mesa3d.org
mesa-dev-19.1.2-r1 installed size:
2576384
```v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10660Support for DANE validation (DNS TLSA RRs)2022-12-21T20:01:44ZMario BiberhoferSupport for DANE validation (DNS TLSA RRs)Hey apk-tools community,
This my first appearance on the alpine-linux stage, please bear with my ignorance.
Is there any interest in adding DANE validation support to apk-tools -- more specifically, libfetch? This (usually) implicates...Hey apk-tools community,
This my first appearance on the alpine-linux stage, please bear with my ignorance.
Is there any interest in adding DANE validation support to apk-tools -- more specifically, libfetch? This (usually) implicates usage of an additional external resolver library, like libunbound. (or a custom implementation to fetch TLSA RRs)
I'd be willing to contribute and maintain this feature. See the attached patch for a hackish, ugly PoC approach. It replaces getaddrinfo() with the corresponding libunbound resolve functions and fetches the TLSA records (if any) after we could successfully connect to the server. The records are then added to the SSL connection in fetch_ssl() (if any).
I validated that this patch works with DANE-TA type RRs using my personal mirror.
Notes on the patch:
- the openssl documentation states that if no TLSA records are added using SSL_dane_tlsa_add(), no DANE validation is performed (see SSL_dane_tlsa_add(3)).
- this patch currently only supports fetching A-Records. IPv6/AAAA RRs are TBD. Also, it surely does not free data correctly and might contain bugs. (I hacked it together in ~1 hour, I hope showing it is not inappropriate) All in all, everyone should press the "unsee" button after viewing it. :-)
Greetings,
Mario
[apk-tools-gitb45415b1096e76f40b32326d2798123f81fe5976_add-dane-validation-1.diff](/uploads/96c8ebbfedcc2068abfd04b6dc8baa98/apk-tools-gitb45415b1096e76f40b32326d2798123f81fe5976_add-dane-validation-1.diff)backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10664apk index multicore2022-12-21T18:50:52ZFredrik Gustafssonapk index multicoreRunning apk index to generate an APKINDEX.tar.gz on a big repo will make one core go to 100% for quite a while. It's not clear where the bottleneck is, but one way of improving apk index speed would be to use multiple cores.Running apk index to generate an APKINDEX.tar.gz on a big repo will make one core go to 100% for quite a while. It's not clear where the bottleneck is, but one way of improving apk index speed would be to use multiple cores.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10665apk add continues to install despite pre-install failure2020-03-27T22:56:03ZMaxim Kouznetsovapk add continues to install despite pre-install failureThe documentation for the Alpine package says the following of the pre-install script:
```
Note the exit 0 at the end. If the script exits with failure (if the user already exist), the package will not be installed and apk add will exit ...The documentation for the Alpine package says the following of the pre-install script:
```
Note the exit 0 at the end. If the script exits with failure (if the user already exist), the package will not be installed and apk add will exit with failure.
```
However, this isn't the case for me, when the pre-install script returns 1 apk *does* print the error `pre-install: script exited with error 1`, but at that point it already installed the package and it will run all the other install scripts (post-install) as if nothing happened.
Here is output where the dependencies and the test package are installed before the pre-install runs:
```
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
(1/3) Installing readline (8.0.0-r0)
(2/3) Installing test_dep (1.0.0-r1)
(3/3) Installing test_pkg (1.0.0.1)
Executing test_pkg-1.0.0.1.pre-install
ERROR: test_pkg-1.0.0.1.pre-install: script exited with error 1
Executing test_pkg-1.0.0.1.post-install
Executing busybox-1.30.1-r3.trigger
```
I also saw this while installing an official package:
```
(1/1) Installing dnsmasq (2.80-r3)
Executing dnsmasq-2.80-r3.pre-install
Executing busybox-1.30.1-r3.trigger
```
So it looks like the pre-install actually executes after the install, and does not abort the installation if it failshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10668Differentiate DNS/TCP/HTTP level errors for more accurate error diagnostics2022-12-21T20:13:48ZLuca WeissDifferentiate DNS/TCP/HTTP level errors for more accurate error diagnosticsFrom looking at the message I cannot tell what failed during the operation. Is my internet connection down? Does the remote server not respond? Does the server return a 404? A 500? Is this something completely different?
apk shouldn't o...From looking at the message I cannot tell what failed during the operation. Is my internet connection down? Does the remote server not respond? Does the server return a 404? A 500? Is this something completely different?
apk shouldn't output generic error messages but exactly what happens so a user can fix the issue.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10669[Feature request] apk add --retry flag.2022-12-21T20:03:12ZJohannes Tegnér[Feature request] apk add --retry flag.### Feature request:
I would love to see a flag added to the apk tool making it possible to "retry" failed package installs. Preferably with a `--retry <times>` option.
What it would do: just try the exact same thing again until `tim...### Feature request:
I would love to see a flag added to the apk tool making it possible to "retry" failed package installs. Preferably with a `--retry <times>` option.
What it would do: just try the exact same thing again until `times` are reached or it is installed.
### Why tho?:
From time to time when I install packages with apk, I get errors, the errors are usually solved by just running the same `get` command again. For example, today I have in my CI scripts been getting the following type of errors on a whole lot of images:
```
/ # apk add --no-cache curl
fetch https://ftp.acc.umu.se/mirror/alpinelinux.org/v3.11/main/x86_64/APKINDEX.tar.gz
fetch https://ftp.acc.umu.se/mirror/alpinelinux.org/v3.11/community/x86_64/APKINDEX.tar.gz
(1/4) Installing ca-certificates (20191127-r0)
(2/4) Installing nghttp2-libs (1.40.0-r0)
(3/4) Installing libcurl (7.67.0-r0)
56% ██████████████████████████████████████████████████████████████████████████████████████████████████ 140118755360072:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1913:
ERROR: libcurl-7.67.0-r0: Permission denied
(4/4) Installing curl (7.67.0-r0)
85% █████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ 140118755360072:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1913:
ERROR: curl-7.67.0-r0: Permission denied
Executing busybox-1.31.1-r8.trigger
Executing ca-certificates-20191127-r0.trigger
2 errors; 6 MiB in 16 packages
```
I would guess that this have to do with some error on the UMU mirrors end (due to the permission error), but sometimes the next "retry" works fine, mostly though, the same error happens again on another package.
Running with `--retry` would ofcourse not remove the issue, while it would make it possible to successfully fetch the package at the end.
---
Another approach could be to allow for secondary repositories to use as fallback:
`/etc/apk/repositories`
```
# Primary repositories.
https://ftp.acc.umu.se/mirror/alpinelinux.org/v3.11/main
https://ftp.acc.umu.se/mirror/alpinelinux.org/v3.11/community
# Fallback repositories.
https://ftp.halifax.rwth-aachen.de/alpine/v3.11/main
https://ftp.halifax.rwth-aachen.de/alpine/v3.11/community
```
I read that this should work, but in my case, it does not seem to work...backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10672Make libapk friendlier to use2022-12-21T19:37:21ZRasmus Thomsenoss@cogitri.devMake libapk friendlier to useHello,
since there's currently quite some talk about apk-tools-3 I thought it might be worth mentioning this too, as libapk currently isn't too nice to use.
There are currently a plugin for GNOME Software and Qt library[1] for usage in...Hello,
since there's currently quite some talk about apk-tools-3 I thought it might be worth mentioning this too, as libapk currently isn't too nice to use.
There are currently a plugin for GNOME Software and Qt library[1] for usage in KDE Discover in the works, but they have to jump through some hoops to get it to work. As of now apk doesn't even always install a shared library, nor a static library or even its headers, making it hard to work with it (!11 tries to fix that though). Additionally most of the convenience functions (e.g. apk_repository_update) aren't in libapk but in apk, forcing other frontends using libapk to reimplement these. It'd be nice if these functions were included in libapk instead, so they could be reused.
1: https://gitlab.com/minlexx/libapk-qtv3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10675Installing packages via apk sometimes installs empty files2020-03-09T20:42:26ZAneesh DurgInstalling packages via apk sometimes installs empty filesI was trying to install python2 and rsync. Running `apk add python2` created a symlink named python2 to an empty file it created named python2.7. Running `apk add rsync` created a file named `rsync` that had the same size as the `rsync` ...I was trying to install python2 and rsync. Running `apk add python2` created a symlink named python2 to an empty file it created named python2.7. Running `apk add rsync` created a file named `rsync` that had the same size as the `rsync` binary, but running hexdump on it revealed it to be full of zeros.
The workaround for now was to uninstall those packages with `apk del` and reinstall.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10676Make apk_*_array_{init,free,resize,copy,add} available in libapk2022-12-21T19:37:22ZRasmus Thomsenoss@cogitri.devMake apk_*_array_{init,free,resize,copy,add} available in libapkIt appears that these aren't available in libapk and are only accessible via the header. As such they appear as visible for projects which are written in languages which don't support C headers (e.g. D, Rust), but aren't actually callabl...It appears that these aren't available in libapk and are only accessible via the header. As such they appear as visible for projects which are written in languages which don't support C headers (e.g. D, Rust), but aren't actually callable by them (trying to call them leads to a linker error).v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10680A higher level API for libapk2022-12-21T19:37:23ZRasmus Thomsenoss@cogitri.devA higher level API for libapkHello,
I think it would be nice if libapk used a friendlier, higher level API for dealing with package operations, so that projects like QtApk or apk-polkit don't have to wrap as much functionality.
Overall, I think the following funct...Hello,
I think it would be nice if libapk used a friendlier, higher level API for dealing with package operations, so that projects like QtApk or apk-polkit don't have to wrap as much functionality.
Overall, I think the following functionality should be exposed via a higher level API:
* Add packages
* Delete packages
* Upgrading packages
* Querying information about a package
* Listing packages (and filtering, e.g. upgradable/installed)
* Open/Close the database
Other bits probably aren't too interesting for projects using libapk.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10684Lose OpenSSL dependency2022-12-21T19:37:23ZPaul SpoorenLose OpenSSL dependencyHi all,
I've been looking a bit for a replacement of OpenWrts current packet manager [opkg](https://git.openwrt.org/?p=project/opkg-lede.git) and apk looks like a good fit. However it has a hard dependency on OpenSSL, while opkg relies ...Hi all,
I've been looking a bit for a replacement of OpenWrts current packet manager [opkg](https://git.openwrt.org/?p=project/opkg-lede.git) and apk looks like a good fit. However it has a hard dependency on OpenSSL, while opkg relies entirely on [signify](https://github.com/aperezdc/signify) (Ed25519) signatures. This allows a small storage footprint required for embedded devices.
Would you generally be open to make OpenSSL a optional dependency?v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10685Exposing security information in apk_package2024-03-08T14:45:40ZRasmus Thomsenoss@cogitri.devExposing security information in apk_packageIt would be nice if apk exposed information about fixed CVEs in a package upgrade so that users could better gauge how important an upgrade is (and users of libapk can set the urgency of an upgrade, e.g. to underline it with red colour t...It would be nice if apk exposed information about fixed CVEs in a package upgrade so that users could better gauge how important an upgrade is (and users of libapk can set the urgency of an upgrade, e.g. to underline it with red colour to show the upgrade is security relevant).v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10690apk fetch doesn't allow to fetch specific version of the package2022-12-21T19:37:23ZMichal Artazovapk fetch doesn't allow to fetch specific version of the package## What I need
When adding a package, I can specify a version like this:
```
apk add foo=1.0.0-r0
```
I need the same thing available with `apk fetch`. Right now it's only possible to fetch a package by its name and it will always pic...## What I need
When adding a package, I can specify a version like this:
```
apk add foo=1.0.0-r0
```
I need the same thing available with `apk fetch`. Right now it's only possible to fetch a package by its name and it will always pick the highest version.
## Why I need it?
I'm building my own Alpine based system running on Raspberry Pi and I'm preparing the local on-disk repo in my CI pipeline from scratch. I also have my own online repository with some official packages and some packages I created myself for my usecase.
When I'm building the on-disk repo, I need to fetch a specific version of my package from my online repo and all it's dependencies, so I can then index the whole thing and generate the repo.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10692Getting all subpackages/"super"packages of an apk_package2022-12-21T19:37:22ZRasmus Thomsenoss@cogitri.devGetting all subpackages/"super"packages of an apk_packageHello,
as far as I can see it's currently not possible to get all subpackages of a package or what the main package of a subpackage is via libapk. This is problematic for apk-polkit, since it allows fine grained upgrades from users: By ...Hello,
as far as I can see it's currently not possible to get all subpackages of a package or what the main package of a subpackage is via libapk. This is problematic for apk-polkit, since it allows fine grained upgrades from users: By default they're presented with an update view in GNOME Software that allows them to either update all packages at once, or to update them one by one:
![image](/uploads/8be111f0dd0b814d55ae8d95bbce1541/image.png)
Note: In this case only flatpaks are ready to be updated, I updated my system before taking the screenshot, but I hope you get the point.
The problem is when an user upgrades a subpackage, e.g. `gnome-software-dbg`. Upgrading the subpackage doesn't upgrade the mainpackage (since apk-polkit specifies `APK_SOLVERF_IGNORE_UPGRADE`, so users don't end up updating more than they asked for), which could lead to unexpected results for the user. It'd be best if apk-polkit could tell subpackages and mainpackages apart from each other somehow, so subpackages can be hidden from the view when they main package also is scheduled to be updated.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10695Warning users about dropped packages during upgrade2022-12-21T19:37:23ZRasmus Thomsenoss@cogitri.devWarning users about dropped packages during upgradeHello,
it'd be nice if apk warned users if a package they've installed isn't available in the repositories anymore because it has been removed (e.g. moved to unmaintained, deleted because deprecated like py2-* things). Orphaned packages...Hello,
it'd be nice if apk warned users if a package they've installed isn't available in the repositories anymore because it has been removed (e.g. moved to unmaintained, deleted because deprecated like py2-* things). Orphaned packages are bound to cause problems to the user at some point, e.g. when they can't upgrade their system anymore because of a soname bump in some library. We had some users having old long removed py2-* packages installed that needed libffi.so.6 but we only had libffi.so.7 available after an upgrade. As such users were unable to upgrade before they removed the unsupported package.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10698`apk fetch` by origin2022-12-21T19:37:22ZAriadne Conillariadne@ariadne.space`apk fetch` by originIt would be nice to make `apk fetch` work based on package origin, so we can ensure that all subpackages are present when we compose a new repo using `apk fetch`.It would be nice to make `apk fetch` work based on package origin, so we can ensure that all subpackages are present when we compose a new repo using `apk fetch`.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10699Making it more obvious that mixing edge and stable isn't supported2022-12-21T20:09:57ZRasmus Thomsenoss@cogitri.devMaking it more obvious that mixing edge and stable isn't supportedI think that many users aren't aware that mixing stable releases and packages from edge isn't supported and might break at any point - e.g. when we bump an soname and rebuild everything but the stable release still has the old library ve...I think that many users aren't aware that mixing stable releases and packages from edge isn't supported and might break at any point - e.g. when we bump an soname and rebuild everything but the stable release still has the old library version in it. As such, I think it'd make sense if APK either explicitly warned you about it, or even better if it threw an error you'd have to override, so something like this wehn when doing `update`/`upgrade`/`add` etc. with mixed repos in `/etc/apk/repositories`:
```
$ apk update
ERROR: Detected repositories from multiple different releases in /etc/apk/repositories.
Please keep in mind that this is unsupported and might break at any point. See $SOME_INFORMATIVE_LINK
for more information. Specify --allow-broken-mixing-releases to keep going anyway.
```backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10704Request: could `apk info` list more clearly what version is actually installe...2022-12-21T20:09:57ZEllieRequest: could `apk info` list more clearly what version is actually installed, and from what repo it originates?I somehow managed to mix edge + stable packages on my install. Apart from other issues I'm having with this (like `apk upgrade -a` not willing to fix it for some reason) what currently bothers me most is that `apk info` somehow really is...I somehow managed to mix edge + stable packages on my install. Apart from other issues I'm having with this (like `apk upgrade -a` not willing to fix it for some reason) what currently bothers me most is that `apk info` somehow really isn't that useful to me / or I fail at reading it:
```
$ sudo apk info nss
nss-3.52.1-r0 description:
Mozilla Network Security Services
nss-3.52.1-r0 webpage:
https://developer.mozilla.org/docs/Mozilla/Projects/NSS
nss-3.52.1-r0 installed size:
3915776
nss-3.54-r0 description:
Mozilla Network Security Services
nss-3.54-r0 webpage:
https://developer.mozilla.org/docs/Mozilla/Projects/NSS
nss-3.54-r0 installed size:
3289088
nss-3.54-r0 description:
Mozilla Network Security Services
nss-3.54-r0 webpage:
https://developer.mozilla.org/docs/Mozilla/Projects/NSS
nss-3.54-r0 installed size:
3289088
$ ls /usr/lib | grep libnss
libnss3.so
libnss3.so.52
libnssckbi-testlib.so
libnssckbi-testlib.so.52
libnssckbi.so
libnssckbi.so.52
libnssdbm3.chk
libnssdbm3.so
libnssdbm3.so.52
libnssutil3.so
libnssutil3.so.52
```
As you can see, it appears I have nss-3.52 installed. However, `apk info` lists two versions, and from all I can tell doesn't specify which one of those is actually installed which would really be essential to know for a situation like this. Additionally, it also doesn't say what repo it got each of the listed versions ones from, so I don't know which one is from edge and which one is from stable even now that I realized I likely have 3.52 installed.
Both those pieces of information would help tremendously in such tricky situations, so could `apk info` possibly be changed to actually specify that?backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10706Suggestion: make apk fix state if an .apk is available but has conflicts2022-12-21T20:03:12ZEllieSuggestion: make apk fix state if an .apk is available but has conflictsI got myself into a corner where gnutls is present but likely the one from Alpine edge, which happens to be the same version as 3.12 but depends on different things.
If I want to install it, `apk fix` just says no APK available, indicat...I got myself into a corner where gnutls is present but likely the one from Alpine edge, which happens to be the same version as 3.12 but depends on different things.
If I want to install it, `apk fix` just says no APK available, indicating it's not in the repos:
```
$ sudo apk fix gnutls
(1/1) [APK unavailable, skipped] Reinstalling gnutls (3.6.14-r0)
OK: 2539 MiB in 789 packages
```
However, what is quite misleading about this is that if I download the .apk via `apk download`, the error is very different:
```
# sudo apk add gnutls-3.6.14-r0.apk
ERROR: unsatisfiable constraints:
nettle-3.5.1-r1:
conflicts: nettle-3.6-r0
satisfies: gnutls-3.6.14-r0[so:libhogweed.so.5] gnutls-3.6.14-r0[so:libnettle.so.7]
nettle-3.6-r0:
conflicts: nettle-3.5.1-r1
satisfies: world[so:libhogweed.so.6] world[so:libnettle.so.8]
epiphany-3.36.3-r0[so:libhogweed.so.6] epiphany-3.36.3-r0[so:libnettle.so.8]
xorg-server-xwayland-1.20.8-r3[so:libnettle.so.8]
```
I think this is what either `apk fix` should additionally display, or maybe a shorter version that hints at it like "Only available APK has conflicts, skipped". Not because what it shows right now is technically wrong, but if an .apk with a matching version to fix from is actually in the repos and it can't be done then it'd be way more helpful to actually tell me why rather than just say there is no .apk.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10712triggers on files2024-01-10T15:53:00ZLuca Weisstriggers on filesCurrently apk-tools only supports triggers on directories but it would be quite convenient to have the possibility to get triggers executed on updated files.
> Apk-tools can "monitor" directories and execute a trigger if any package ins...Currently apk-tools only supports triggers on directories but it would be quite convenient to have the possibility to get triggers executed on updated files.
> Apk-tools can "monitor" directories and execute a trigger if any package installed/uninstalled any file in the monitored dir.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10713[Feature request] Add mirrors fallbacking2022-12-21T18:50:52Zmmkhitaryan[Feature request] Add mirrors fallbackingSometimes a mirror can be inaccessible because of a mirror maintenance etc. It would be cool if a mirror is not accesible, alpine package manager retried the same package, but on other mirror.
If I have repo list like:
/etc/apk/reposit...Sometimes a mirror can be inaccessible because of a mirror maintenance etc. It would be cool if a mirror is not accesible, alpine package manager retried the same package, but on other mirror.
If I have repo list like:
/etc/apk/repositories ```
http://nl.alpinelinux.org/alpine/v3.7/main
http://mirror.yandex.ru/mirrors/alpine/
```
The package manager tries to download package from mirror.yandex.ru. If package manager can not reach the server because of network error, it retries downloading, but with a mirror upper (nl.alpinelinux.org).v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10716Integration of libhydrogen for package/index signatures2022-12-21T19:37:23ZPaul SpoorenIntegration of libhydrogen for package/index signaturesThe library [libhydrogen](https://github.com/jedisct1/libhydrogen) offers a very simple to sign and verify images. It's especially designed for embedded devices and is both fast while using very short signatures.
As an effort related to...The library [libhydrogen](https://github.com/jedisct1/libhydrogen) offers a very simple to sign and verify images. It's especially designed for embedded devices and is both fast while using very short signatures.
As an effort related to #10684 I'd be happy to integrate libhydrogen as an additional mechanism for certificate verification. While RSA etc should stay in place, maybe it could be optionally *ifdefed-out*v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10722Support for Optional Dependencies2024-01-21T09:12:24ZBenSupport for Optional DependenciesSome software has dependencies that are not strictly required for core operation, but add functionality. It would be helpful if there was a way to represent this in APKs, notify the user of these during installation, and allow the user t...Some software has dependencies that are not strictly required for core operation, but add functionality. It would be helpful if there was a way to represent this in APKs, notify the user of these during installation, and allow the user to install them as well when the -i flag is provided.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10732apk policy: add feature to hold/pin packages2022-12-21T19:37:22ZJ0WIapk policy: add feature to hold/pin packagesI'd like to prevent apk from installing or upgrading specific packages.
Use cases are preventing apk from overriding custom builds or prevent a specific broken update while others keep updating.I'd like to prevent apk from installing or upgrading specific packages.
Use cases are preventing apk from overriding custom builds or prevent a specific broken update while others keep updating.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10735"No error information" when installing packages built on edge/3.132021-01-24T20:41:21ZRasmus Thomsenoss@cogitri.dev"No error information" when installing packages built on edge/3.13See e.g. https://gitlab.alpinelinux.org/alpine/aports/-/issues/12296#note_137729
Seems to be reproducible on all systems. At least the error message should be better imhoSee e.g. https://gitlab.alpinelinux.org/alpine/aports/-/issues/12296#note_137729
Seems to be reproducible on all systems. At least the error message should be better imhohttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10739Split fetch I/O into separate process2022-12-21T19:37:22ZAriadne Conillariadne@ariadne.spaceSplit fetch I/O into separate processIn the beginning, we used to use a separate process for fetches.
I think it would be nice to reimplement this in a way similar to `apt`, where there would be `/lib/apk/methods/http` and so on.
It would also be nice to drop root privile...In the beginning, we used to use a separate process for fetches.
I think it would be nice to reimplement this in a way similar to `apt`, where there would be `/lib/apk/methods/http` and so on.
It would also be nice to drop root privileges when fetching.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10740adbdump produces invalid YAML2022-12-21T19:37:21ZAriadne Conillariadne@ariadne.spaceadbdump produces invalid YAMLThe YAML generated by `adbdump` applet does not generate YAML which validates when processed with `yq`.
For example, `./src/apk adbdump ./installed.adb | yq e '.packages[0]'` generates a document which fails validation if coreutils is i...The YAML generated by `adbdump` applet does not generate YAML which validates when processed with `yq`.
For example, `./src/apk adbdump ./installed.adb | yq e '.packages[0]'` generates a document which fails validation if coreutils is installed due to `/usr/bin/[`.
This is probably something @fabled is already aware of, but I figure opening a bug about it is better than not.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10743lbu commit fails storing correct permissions on lbu include directories2022-08-02T19:17:39Zmacmpilbu commit fails storing correct permissions on lbu include directoriesI'm running Alpine 3.13 on disk-less setup and installed mpd.\
I need to save/restore some music files within `/var/lib/mpd/music`\
`/var/lib/mpd/music` is created at mpd install with mpd:audio\
If I add a file root:root as `/var/lib/mpd...I'm running Alpine 3.13 on disk-less setup and installed mpd.\
I need to save/restore some music files within `/var/lib/mpd/music`\
`/var/lib/mpd/music` is created at mpd install with mpd:audio\
If I add a file root:root as `/var/lib/mpd/music/test` and then `lbu include /var/lib/mpd/music/test` and `lbu commit -d`, then at reboot `/var/lib/mpd` and `/var/lib/mpd/music` become root:root and original permissions are altered.
Any suggested workaround?
Note: this looks similar to older issue https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/1241https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10744Cryptographic module abstraction2022-12-21T19:37:21ZAriadne Conillariadne@ariadne.spaceCryptographic module abstractionAt present, apk-tools makes direct use of libcrypto to do signature verification, signing, etc.
It would be nice to factor this out so that we can eventually drop the libcrypto dependency with something better.
Similarly, it would be n...At present, apk-tools makes direct use of libcrypto to do signature verification, signing, etc.
It would be nice to factor this out so that we can eventually drop the libcrypto dependency with something better.
Similarly, it would be nice to replace our use of libssl with libtls in our libfetch fork, for the same reason: multiple libtls implementations exist, and we can just use whatever one we want (for now, libtls-standalone, but later perhaps libtls-bearssl instead.)v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10745Allow repository precedence when multiple instances of the same repository ex...2022-12-21T20:01:44ZMorgan HeinAllow repository precedence when multiple instances of the same repository exist in /etc/apk/repositoriesI have the following situation:
- Repository A is a custom compiled set of packages that also exist in
the public repository. This repository has the pkgs compiled with
extra security features and/or some unique flags set.
- ...I have the following situation:
- Repository A is a custom compiled set of packages that also exist in
the public repository. This repository has the pkgs compiled with
extra security features and/or some unique flags set.
- Repository B is a full mirror of the official repository.
What i’d like to happen is list both repositories in the
/etc/apk/repositories file, and have the clients prefer downloading all
pkgs from Repo A. In the case that the file doesn’t exist in Repo A,
then download from Repo B.
This, currently, doesn’t seem possible. After adding both repositories,
clients sometimes download from A, and sometimes download from B,
regardless of what is available in A.
The ability to add multiple repositories, with precedence, would be very
helpful in this situation.
Thanks,
Morgan
*(from redmine: issue id 9409, created on 2018-09-11)*backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10747When a package stops replacing a file, that file gets uninstalled completely ...2022-12-21T18:50:51ZBart RibbersWhen a package stops replacing a file, that file gets uninstalled completely rather than switching back to the version of the original providing packageIn postmarketOS we are currently overwriting `/etc/sudoers` from sudo in one of our packages but we want to stop doing that in [pmaports!2181](https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2181). However while testing this ch...In postmarketOS we are currently overwriting `/etc/sudoers` from sudo in one of our packages but we want to stop doing that in [pmaports!2181](https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2181). However while testing this change we noticed that rather than the file being either reverted back to what sudo itself provides or just being left there, it would get uninstalled instead.
This seems strange, seeing there is still a package on the system that provides (and needs!) that file, it's just the original providing package again. To "fix" it we need to reinstall sudo to let it put it's own file back again, but of course we can't tell all our users to manually run `apk fix sudo` after a random system upgrade.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10755replaced files are not restored when uninstalling replacing package2022-12-21T20:28:45ZAlex Xu (Hello71)replaced files are not restored when uninstalling replacing packageexample: install libc6-compat, then install gcompat, then remove gcompat. expected behavior is libc6-compat files are restored, but this doesn't happenexample: install libc6-compat, then install gcompat, then remove gcompat. expected behavior is libc6-compat files are restored, but this doesn't happenv3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10756Document proxy support better2022-12-21T19:39:45ZHadmut DanischDocument proxy support betterThis is rather a documentation than a software issue, but the wiki didn't let me write to the discussion page of the apk management.
When creating virtual images (especially with docker) with alpine (what it is just perfect for), it ta...This is rather a documentation than a software issue, but the wiki didn't let me write to the discussion page of the apk management.
When creating virtual images (especially with docker) with alpine (what it is just perfect for), it takes typically lots of iterations to recreate the image and have lots of apk packages installed from scratch. Since every installation run typically starts with a fresh, clean system without a persistent cache dir, there is no point in using the local cache feature of apk.
Fetching the images again with every run is time consuming, creates network traffic (possibly expensive), and puts load on alpine's servers. So there's good reason to try to have some local mirror/cache. Unfortunately I didn't find any hint in the docs on what's the recommended way. They are just mentioning apk's local cache function.
Other package managers like apt, yum, gem allow to configure external caches/proxies.
My guess (not yet tested) would be hat apk should honor a https_proxy environment variable pointing to an external, HTTPS-intercepting cache after installing it's certificate to /etc/ssl/certs, but I didn't try this yet.
It would therefore be good to have a section in the documentation about how to use apk with some external cache mechanism.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10758Ignored / phantom packages2022-12-21T19:37:22ZAlan DiwixIgnored / phantom packagesIs there any way to replace a package with "phantom" version of it that neither replaces nor introduces any files, but satisfies the same dependencies as original?
For example xbps' ignorepkg:
https://man.voidlinux.org/xbps.d.5
If not, ...Is there any way to replace a package with "phantom" version of it that neither replaces nor introduces any files, but satisfies the same dependencies as original?
For example xbps' ignorepkg:
https://man.voidlinux.org/xbps.d.5
If not, I guess this would be a feature request.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10760Parallelize triggers2024-01-10T16:03:46ZAriadne Conillariadne@ariadne.spaceParallelize triggersSome triggers can take multiple seconds (up to minutes) to run, like the `mkinitfs` trigger.
It would be a nice win to run all triggers in parallel.
Another thing to consider might be running triggers in the background.Some triggers can take multiple seconds (up to minutes) to run, like the `mkinitfs` trigger.
It would be a nice win to run all triggers in parallel.
Another thing to consider might be running triggers in the background.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10765Add support for variables in /etc/apk/repositories like Yum has2022-12-21T19:39:44ZChristoph ObexerAdd support for variables in /etc/apk/repositories like Yum hasThis would IMO solve #10756 by replacing the repo in /etc/apk/repositories by a caching proxy
An example need of such a feature is documented in the wiki:
https://wiki.alpinelinux.org/wiki/Alpine_newbie_apk_packages#New_users:_installin...This would IMO solve #10756 by replacing the repo in /etc/apk/repositories by a caching proxy
An example need of such a feature is documented in the wiki:
https://wiki.alpinelinux.org/wiki/Alpine_newbie_apk_packages#New_users:_installing_needed_packages
```
# old /etc/apk/repositories from the example above
cat > /etc/apk/repositories << EOF; $(echo)
http://dl-cdn.alpinelinux.org/alpine/v$(cat /etc/alpine-release | cut -d'.' -f1,2)/main
EOF
```
would become:
```
# proposed /etc/apk/repositories
cat > /etc/apk/repositories << EOF; $(echo)
http://dl-cdn.alpinelinux.org/alpine/v\$releasever/main
EOF
```
Now that is of little use, BUT we use Artifactory as cache and thus point our Alpine containers to a repo mirror there... but need a separate repo file for every alpine release or synthesize a repo file based on the alpine release... that sounds easy enough but the code that needs to synthesize the repo file needs to be running outside the container and thus has to guess the correct release number from docker tags for various base images (node, go, java, ...)...
We would love to be able to just bind mount `/etc/apk/repositories` with our artifactory repositories (and credentials) without fancy magic and use `$releasever` as a placeholder for the version inside them.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10769[RFC] rename apk to avoid confusion with Android package format2022-12-21T19:39:44ZPaul Spooren[RFC] rename apk to avoid confusion with Android package formatWhenever looking up issues or code around the `apk` package manage I'll likely find results describing corner cases of the Android package format `.apk`.
I'm wondering if a *better* name could be found in some future. Clearly this is no...Whenever looking up issues or code around the `apk` package manage I'll likely find results describing corner cases of the Android package format `.apk`.
I'm wondering if a *better* name could be found in some future. Clearly this is not a pushing issues but I'm a bit concerned that once `apk` is used for *OpenWrt*, a flood of obscure error messages and confused user appear.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10771pkgusers/pkggroups + install -o/-g doesn't stick in /var2023-12-12T22:22:03ZDrew DeVaultpkgusers/pkggroups + install -o/-g doesn't stick in /varhttps://git.sr.ht/~sircmpwn/sr.ht-apkbuilds/tree/master/item/sr.ht/sr.ht-uacme/APKBUILD#L43
This does not seem to work; I have to add a post-install to force the desired user/group. The tarball looks right, though, may be an apk-tools i...https://git.sr.ht/~sircmpwn/sr.ht-apkbuilds/tree/master/item/sr.ht/sr.ht-uacme/APKBUILD#L43
This does not seem to work; I have to add a post-install to force the desired user/group. The tarball looks right, though, may be an apk-tools issue?v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10773apk bash-completion2022-12-21T19:39:44ZJ0WIapk bash-completionapk should ship it's own completion file. This makes it easier for both experienced and new users of Alpine to deal with software packages.apk should ship it's own completion file. This makes it easier for both experienced and new users of Alpine to deal with software packages.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10779apk3: mkpkg: support explicit ownership of files?2023-12-12T22:15:38ZDaniel Kolesaapk3: mkpkg: support explicit ownership of files?After investigating apk3 for my downstream distro use a bit, I came across one potential blocker. I need to be able to supply a way to set user/group ownership on certain files - currently I have my own generator for the packages, so I c...After investigating apk3 for my downstream distro use a bit, I came across one potential blocker. I need to be able to supply a way to set user/group ownership on certain files - currently I have my own generator for the packages, so I can do that just fine, but if creating packages becomes apk's responsibility, this is no longer going to be possible.
The reason for this is that in my case the builds run unprivileged in a sandbox that uses namespaces. This precludes creation of new users/groups (or rather, I can create them, but trying to use `chown` for any user/group other than the current primary will result in `EINVAL` - this makes sense because as an unprivileged user, the user within the namespace is mapped to your own user, and you can't really touch other uids and gids).
However, I don't really care about ownership of the files within the sandbox per se. All I care about is the ownership within the archive, since that's what will determine what user/group the files will be owned by. Would it be possible to add some kind of option to explicitly override ownerships on certain files, as well as ensure the ownership for everything else goes to root? (since things would be run with an unprivileged user effective uid/gid). Alternatively, maybe you have a better idea how to do this?
Thanksv3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10780support generation of an SBOM file describing the running system2022-12-21T19:37:22ZAriadne Conillariadne@ariadne.spacesupport generation of an SBOM file describing the running systemA frequent request I have gotten lately is that Alpine should support generating an SBOM file. An SBOM file is an emergent standard being pushed forward by the NTIA, which is designed to help auditors check for licensing compliance and ...A frequent request I have gotten lately is that Alpine should support generating an SBOM file. An SBOM file is an emergent standard being pushed forward by the NTIA, which is designed to help auditors check for licensing compliance and remediation compliance.
An SBOM file describes a system as a set of facts about each package (component), such as the package name, the hashes of every file belonging to it, the license and copyright declarations, the supplier (package maintainer), and any upstream contacts for the package. The NTIA have a report of [what they consider to be baseline](https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf).
Excluding the upstream contact information and copyright declarations, which really need to be done anyway for licensing compliance reasons, we already have all of the necessary information to construct a baseline SBOM.
The most common format for SBOMs is the SPDX format, I suggest we would want to implement this format.
The value to Alpine users should be obvious: we already have all the necessary information for them to generate this data, but right now, Alpine users needing to generate SBOMs have to use non-free software to do it.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10787Optional architecture adding to repository path2022-12-21T19:01:25ZPaul SpoorenOptional architecture adding to repository pathWhile Alpine repositories follow the structure `<feedname>/<arch>`, it's the other way around for OpenWrt. While this would be easy to switch on the OpenWrt side, we also have target specific packages which use unique path without the ar...While Alpine repositories follow the structure `<feedname>/<arch>`, it's the other way around for OpenWrt. While this would be easy to switch on the OpenWrt side, we also have target specific packages which use unique path without the architecture in it.
It would be useful to have the configuration option to disable *architecture addition* to repositories.
A workaround is to create a symlink like `ln -s . <arch>` but that's not ideal.
Example target specific repository:
* https://downloads.openwrt.org/snapshots/targets/x86/64/packages/
Example arch specific repository (feed *base*):
* https://downloads.openwrt.org/snapshots/packages/x86_64/base/v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10795Clarification on `passwd` field in adb file2022-12-21T19:37:21ZPaul SpoorenClarification on `passwd` field in adb fileLooking at [apk_adb.c](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/apk_adb.c#L508) I see a commented `passwd` entry. Is this supposed to allow the creation of `passwd` entries on a package basis?
I'm currently look...Looking at [apk_adb.c](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/apk_adb.c#L508) I see a commented `passwd` entry. Is this supposed to allow the creation of `passwd` entries on a package basis?
I'm currently looking for a solution to add users/groups during package installation. Currently this is solved by a custom post-install wrapper script, however a *in-APK* solution would be nicer.v3.1https://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/10801Annoy the user when pinning packages from incompatible repositories2022-12-21T19:37:22ZAlex Xu (Hello71)Annoy the user when pinning packages from incompatible repositoriesMany users are following poorly-written tutorials and installing packages from incompatible repositories. For some non-Alpine distros, this may be allowed, but for Alpine it is not permitted to mix packages from different releases. There...Many users are following poorly-written tutorials and installing packages from incompatible repositories. For some non-Alpine distros, this may be allowed, but for Alpine it is not permitted to mix packages from different releases. There should be some mechanism for apk to tell the user that this is not supported. Two simple heuristics for Alpine would be checking the repository URL and the repository version, and if these don't match then raise an error. However, this may not work for third-party repositories or non-Alpine distros.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10805apk3: signing key generation applet2022-12-21T19:37:21ZDaniel Kolesaapk3: signing key generation appletWith the move to apk3, it will no longer be necessary to directly use `openssl` for signing, but apparently it is still necessary to use it to generate keys. Maybe apk should provide an applet to deal with that, to be able to drop direct...With the move to apk3, it will no longer be necessary to directly use `openssl` for signing, but apparently it is still necessary to use it to generate keys. Maybe apk should provide an applet to deal with that, to be able to drop direct `openssl` usage from tooling entirely?
Not entirely sure what the best interface to it would be. It probably does not have to be too user friendly, since its main purpose would be to be used from tooling (like `abuild` or others)v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10808Progress bar flushed by script execution2022-12-21T19:37:22ZPaul SpoorenProgress bar flushed by script executionIn OpenWrt every script executes a default `post-install` script which thereby always flushes the progress bar, it's only flickering around. Would it be possible to write the package installation progress bar after printing the execution...In OpenWrt every script executes a default `post-install` script which thereby always flushes the progress bar, it's only flickering around. Would it be possible to write the package installation progress bar after printing the execution message?
```
(15/139) Installing ucode-mod-uci (0_git20220126-r1)
Executing ucode-mod-uci_0_git20220126-r1.post-install
(16/139) Installing firewall4 (0_git20220128-r1)
Executing firewall4_0_git20220128-r1.post-install
(17/139) Installing ubi-utils (2.1.4-r1)
Executing ubi-utils_2.1.4-r1.post-install
(18/139) Installing fstools (0_git20211116-r2)
Executing fstools_0_git20211116-r2.post-install
(19/139) Installing getrandom (0_git20210803-r2)
Executing getrandom_0_git20210803-r2.post-install
(20/139) Installing hostapd-common (0_git20210522-r67)
Executing hostapd-common_0_git20210522-r67.post-install
...
```v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10813enhanced structured data for copyright tracking2022-12-21T19:37:22ZAriadne Conillariadne@ariadne.spaceenhanced structured data for copyright trackingAt work, we are writing a build-tool which generates APKv3 files as output. However, we would like to capture more of the copyright/license metadata than just the `license` field of `APKBUILD`.
I propose the following:
```
copyright:
...At work, we are writing a build-tool which generates APKv3 files as output. However, we would like to capture more of the copyright/license metadata than just the `license` field of `APKBUILD`.
I propose the following:
```
copyright:
- path: "[glob mask relevant to $srcdir]"
license: "[SPDX identifier, like old `license` field]"
attestations:
- "Copyright (c) 20XX foobar"
- "Copyright (c) 20XX baz"
```
An `APKBUILD` with `license="ISC"` would then map to:
```
copyright:
- path: "*"
license: "ISC"
```
If this seems agreeable, I can work on a patch next week for this. It is related to the SBOM work, see #10780.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10816Store package filename in database2024-03-25T15:53:51ZPaul SpoorenStore package filename in databaseCurrently the filename of packages is automatically generated based on the following structure:
```
<name>-<version>.apk
```
In OpenWrt, we currently use the structure below:
```
<name>_<version>-<arch>.ipk
```
We even use script for...Currently the filename of packages is automatically generated based on the following structure:
```
<name>-<version>.apk
```
In OpenWrt, we currently use the structure below:
```
<name>_<version>-<arch>.ipk
```
We even use script for cleaning up outdated packages that specifically look for the underscore (`<name>_`) in filenames.
I'm wondering if we could simply store the filename inside the index instead of enforcing a specific structure. For example, if I only provide a single package in multiple architectures, I could just fill a single folder with `<package>-<version>-<arch>.apk` instead of maintaining a variety of subfolders.
Thoughts?v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10817licensing2022-12-21T19:32:49ZAriadne Conillariadne@ariadne.spacelicensingThere are a few minor licensing nitpicks we should clean up. As background, by far, the codebase was written by @fabled, with the majority of other contributions being @ncopa and myself, I think we have sufficient legal and moral author...There are a few minor licensing nitpicks we should clean up. As background, by far, the codebase was written by @fabled, with the majority of other contributions being @ncopa and myself, I think we have sufficient legal and moral authority to do these things, as well I think they are not really controversial.
## Lack of OpenSSL license exception
`apk-tools` is licensed as `GPL-2.0-only`. This means that even when Alpine switches to OpenSSL 3, this will not be sufficient, as the Apache license imposes additional restrictions (e.g. the software patents stuff) that are not in GPLv2. GPLv3 does add an exception allowing Apache-2 code to link to it, but the `GPL-2.0-only` license was chosen intentionally.
We can fix this by adding a license exception grant for OpenSSL. We may want to add a general exception for Apache 2.0 licensed programs as well.
## Makefile-based build system is `GPL-3.0-only`
This will likely be fixed by just removing the old build system once Muon is ready.
## `libapk` is `GPL-2.0-only`
It seems like we should relax the license on `libapk` to be LGPLv2.1. This would allow programs to link to `libapk` such as package management frontends, without worrying about the GPL, which seems ideal for encouraging further adoption of `libapk` and APK at large.
@fabled what do you think?v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10819manage user and group creation/deletion directly2023-12-19T12:23:07ZAriadne Conillariadne@ariadne.spacemanage user and group creation/deletion directlyPresently, the majority of pre-install/post-install scripts in Alpine are doing user/group management. If apk did this instead, we could drop these scripts in the future.Presently, the majority of pre-install/post-install scripts in Alpine are doing user/group management. If apk did this instead, we could drop these scripts in the future.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10829Understanding .apk-new protected files behavior2023-12-02T13:31:07ZYann BizeulUnderstanding .apk-new protected files behaviorMy projects is made of several scripts and docker compose file, installed in `/usr/local/myproject/`.
The user can alter docker-compose behavior by editing a `/usr/local/myproject/docker-compose.override.yaml` file that is installed by ...My projects is made of several scripts and docker compose file, installed in `/usr/local/myproject/`.
The user can alter docker-compose behavior by editing a `/usr/local/myproject/docker-compose.override.yaml` file that is installed by default with pretty much everything commented out, they can go in and add their own configuration.
The problem is that this file gets overwritten with a package update, my assumption after doing some research is that apk doesn't consider this file a being _protected_ and assumes it has to be overwritten with the package version.
What I would like, is instead to replace the file if it has been untouched, or if it has, copy the distribution file as `.apk-new` which seems to be the standard behavior regarding configuration files.
I'm thinking the path I use isn't considered as appropriate for APK to adopt protected mode.
- Is there a way to indicate APK that a given file is a configuration file and shouldn't be overwritten ?
- Where can I find more information about that feature ? (does it look at specific folders, specific file extensions ?)
Thanks for your help.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10832CI tests on macOS2022-12-21T19:39:45ZPaul SpoorenCI tests on macOSAs a follow up of https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10794 it would be nice to add CI tests running on macOS.As a follow up of https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10794 it would be nice to add CI tests running on macOS.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10842retain signatures of installed packages in apkdb2022-12-21T18:50:51ZAriadne Conillariadne@ariadne.spaceretain signatures of installed packages in apkdbA current problem with security scanners are that they just check the version field and assume all packages are coming from the same ecosystem.
This means that, as an attacker, I can build an old version (say nginx `1.20.2-r0`) of a pac...A current problem with security scanners are that they just check the version field and assume all packages are coming from the same ecosystem.
This means that, as an attacker, I can build an old version (say nginx `1.20.2-r0`) of a package which has vulnerabilities, and distribute it through an alternative repository, while saying it is the latest version (nginx `1.20.2-r9000`), and the security scanners will say this is entirely fine, because the version is higher than the last vulnerable one.
We already have a useful piece of data that can be used to correlate whether or not a package legitimately comes from the distribution ecosystem: the package signature. If we retain it, then scanners can check the signature to determine which ecosystem (and thus, security feeds) the package should be checked against (or it can warn that the package does not come from an ecosystem supported by that scanner).v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10844solver tries to swap packages when presented with a multi-arch index2022-12-21T19:39:44ZAriadne Conillariadne@ariadne.spacesolver tries to swap packages when presented with a multi-arch indexDue to a bug we recently created an index which had some packages for `aarch64` and other packages for `x86_64`.
When we tried to install packages using this repo, it tried to swap the dependencies for the `aarch64` packages that were i...Due to a bug we recently created an index which had some packages for `aarch64` and other packages for `x86_64`.
When we tried to install packages using this repo, it tried to swap the dependencies for the `aarch64` packages that were in the repo, even though they were already installed as `x86_64` packages.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10845implement support for SCT signature scheme in apkv32022-12-21T18:56:12ZAriadne Conillariadne@ariadne.spaceimplement support for SCT signature scheme in apkv3[Fulcio](https://github.com/sigstore/fulcio) is a reference implementation of the SCT signature scheme, which allows for signing keys to be created on demand and retired after signing an artifact.
In our downstream distribution, we pres...[Fulcio](https://github.com/sigstore/fulcio) is a reference implementation of the SCT signature scheme, which allows for signing keys to be created on demand and retired after signing an artifact.
In our downstream distribution, we presently generate APKv2 files with signatures like `.SIGN.FULCIO.[OIDC-identity-hash]` and validate their signatures when including them in our repositories. This works fine because of the APKv2 trust model.
However, APKv3 does not allow us to just "invent" a new signature scheme and use it for our own purposes. Accordingly we would like to add a signature type "fulcio" which stores the SCT signature data, but otherwise uses the APKv2 trust model (for now).
Thoughts?v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10846Multiple maintainers in metadata?2022-12-21T18:53:53ZPaul SpoorenMultiple maintainers in metadata?Is it possible to store multiple maintainers in the package metadata or is it always a single string only?Is it possible to store multiple maintainers in the package metadata or is it always a single string only?v3.0https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10851Support files changing owner in the same transaction without replaces=?2022-12-21T18:56:12ZOliver SmithSupport files changing owner in the same transaction without replaces=?During an upgrade, sometimes a new-package gets installed instead of an old-package, and takes over files from old-package. If that is the case, the new-package must have `replaces="old-package"` or else we get an error like the followin...During an upgrade, sometimes a new-package gets installed instead of an old-package, and takes over files from old-package. If that is the case, the new-package must have `replaces="old-package"` or else we get an error like the following:
```
(491/542) Installing bemenu (0.6.7-r0)
ERROR: bemenu-0.6.7-r0: trying to overwrite usr/bin/bemenu owned by sxmo-bemenu-0.6.3.0-r0.
```
(example from [aports!34975](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/34975))
In other words:
* old
* a package depends on "sxmo-bemenu"
* new
* the same package does not depend on "sxmo-bemenu" anymore, but instead on "bemenu"
* bemenu owns the files now
Since it's in the same transaction, and running `apk fix` afterwards will resolve it, I wonder if apk could just automatically recognize this during the upgrade and not print an error even if there is no `replaces=` present.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10856apk3: failure upgrading packages if newer version replaces file with directory2022-12-21T18:56:12ZDaniel Kolesaapk3: failure upgrading packages if newer version replaces file with directoryOne will get a `not a directory` error when trying to upgrade a package and the newer version has a directory where the previous version had a file.One will get a `not a directory` error when trying to upgrade a package and the newer version has a directory where the previous version had a file.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10858`apk add ...` should attempt to redownload an apk package with a bad signatur...2022-12-21T18:56:11ZEllie`apk add ...` should attempt to redownload an apk package with a bad signature at least once during the command run`apk add ...` should attempt to redownload an apk package with a bad signature at least once during the command run. Instead it just gets stuck dumbfounded and always gives the same failed output even if the command is rerun:
```
$ sudo...`apk add ...` should attempt to redownload an apk package with a bad signature at least once during the command run. Instead it just gets stuck dumbfounded and always gives the same failed output even if the command is rerun:
```
$ sudo apk add py3-pip
(1/12) Installing py3-contextlib2 (21.6.0-r2)
(2/12) Installing py3-tomli (2.0.1-r1)
(3/12) Installing py3-pep517 (0.12.0-r2)
(4/12) Installing py3-six (1.16.0-r1)
(5/12) Installing py3-retrying (1.3.3-r3)
2% ██
(6/12) Installing py3-appdirs (1.4.4-r3)
2% ██
3% ██
(7/12) Installing py3-more-itertools (8.13.0-r0)
3% ██
4% ███
5% ███
(8/12) Installing py3-ordered-set (4.0.2-r3)
5% ████
(9/12) Installing py3-parsing (2.4.7-r3)
5% ████
ERROR: py3-parsing-2.4.7-r3: IO ERROR
(10/12) Installing py3-packaging (21.3-r0)
8% ██████
ERROR: py3-packaging-21.3-r0: BAD signature
(11/12) Installing py3-setuptools (59.4.0-r0)
10% ███████
ERROR: py3-setuptools-59.4.0-r0: BAD signature
(12/12) Installing py3-pip (22.1.1-r0)
23% █████████████████
ERROR: py3-pip-22.1.1-r0: BAD signature
100% █████████████████████████████████████4 errors; 2154 MiB in 814 packages
$
```
For such an obvious culprit, I would expect it to do *something* when it runs into broken packages like that. at the very least when I try running the command again.
I saw this with apk 2.12.9 on postmarketOS 22.06.v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10861implement support for OCI registries2022-12-21T18:56:11ZAriadne Conillariadne@ariadne.spaceimplement support for OCI registriesWith projects such as ORAS (OCI Registry as Storage), it may be interesting to support fetching apk packages as if they were objects stored in OCI registries. This would allow users to distribute apk packages at zero cost by using pre-e...With projects such as ORAS (OCI Registry as Storage), it may be interesting to support fetching apk packages as if they were objects stored in OCI registries. This would allow users to distribute apk packages at zero cost by using pre-existing OCI registries such as DockerHub, GHCR, etc.
Other package managers, such as Homebrew, have implemented support for this distribution method. I believe OpenWrt developers have expressed interest in this as well.
(This would be for something after apk 3.0 release.)v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10862Fetch fails to detect broken IPv62022-12-21T19:39:44ZReuben LifshayFetch fails to detect broken IPv6If apk is running in a dual stack environment where AAAA records are returned but IPv6 packets do not go through fetch will try to connect only to the v6 addresses and will take a very long time to fail and fall back to v4. In my case, t...If apk is running in a dual stack environment where AAAA records are returned but IPv6 packets do not go through fetch will try to connect only to the v6 addresses and will take a very long time to fail and fall back to v4. In my case, this is with building docker images.
Other utilities such as `curl` work correctly in the same situation because they use the Happy Eyeballs algorithm ([RFC 8305](https://www.rfc-editor.org/rfc/rfc8305)).
apk:
```
~ # apk update
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
...(hangs until timeout)
```
curl:
```
~ # curl -vI https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
* Trying 2a04:4e42:600::645:443...
* Trying 151.101.194.133:443...
* Connected to dl-cdn.alpinelinux.org (151.101.194.133) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...CLIPPED
```
curl IPv6 only:
```
~ # curl -6 -vI https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
* Trying 2a04:4e42::645:443...
...(hangs until timeout)
```backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10865Add info on where each package in apk upgrade is coming from2022-12-21T18:56:12ZJustinAdd info on where each package in apk upgrade is coming fromIf the user has multiple repositories installed, show where each package is coming from.
For instance I have a script that does this with apt data and spits out this:
```
+------------------+-----------------+-------------------+------...If the user has multiple repositories installed, show where each package is coming from.
For instance I have a script that does this with apt data and spits out this:
```
+------------------+-----------------+-------------------+-------------------+
| Package Name | Repository | Current Version | New Version |
+------------------+-----------------+-------------------+-------------------+
| kpartx | focal-security | 0.8.3-1ubuntu2 | 0.8.3-1ubuntu2.1 |
| libexpat1 | focal-security | 2.2.9-1ubuntu0.4 | 2.2.9-1ubuntu0.5 |
| multipath-tools | focal-security | 0.8.3-1ubuntu2 | 0.8.3-1ubuntu2.1 |
+------------------+-----------------+-------------------+-------------------+
```v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10867Documentation on cmd:PATTERN, so:PATTERN etc. missing from apk-search.82022-12-26T13:28:50ZPaul W. Rankinhello@paulwrankin.comDocumentation on cmd:PATTERN, so:PATTERN etc. missing from apk-search.8I'm not sure where I learnt that `apk-search(8)` could accept `cmd:PATTERN` but it seems it was not the man page.
Upon trying to learn which prefixes are available the documentation is missing.I'm not sure where I learnt that `apk-search(8)` could accept `cmd:PATTERN` but it seems it was not the man page.
Upon trying to learn which prefixes are available the documentation is missing.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10868add vendor field to apkv2/apkv3 control data and apkdb2024-03-08T14:45:39ZAriadne Conillariadne@ariadne.spaceadd vendor field to apkv2/apkv3 control data and apkdbSoftware component analysis tools (and related software such as vulnerability scanning tools) use CPE identifiers and Package URLs (PURLs) to determine the ecosystem a software component originates from.
At present, the apkdb does not c...Software component analysis tools (and related software such as vulnerability scanning tools) use CPE identifiers and Package URLs (PURLs) to determine the ecosystem a software component originates from.
At present, the apkdb does not contain this information, so SCA tools assume that all packages originate from the distribution. This causes problems when trying to understand the relationship between software components and their suppliers, to do things like find out about remediated CVEs, as the calculated CPE identifiers and PURLs are matched to the wrong supplier.
Since Alpine 3.16, we have shipped `/etc/secfixes.d/$vendorlabel`, e.g. `/etc/secfixes.d/alpine`, files in the baselayout. Some other apk distributions which use the same secdb format have done the same such as $dayjob's Wolfi GNU/Linux distribution. By providing a vendor tag in the APK control data and apkdb which matches to these `/etc/secfixes.d` files, we can correctly map relevant security remediation feeds to the packages.
I'm happy to work on this if @fabled agrees we should do this.v3.0https://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#L382https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10873tooling for repository mirroring2023-04-11T17:55:40ZTimo Terästooling for repository mirroringImprove existing applets (e.g. `fetch`) or create new one(s) to allow for:
- downloading repository index and all packages in it
- support incremental download with modified-since timestamp (or possibly compared to an old index)
- rec...Improve existing applets (e.g. `fetch`) or create new one(s) to allow for:
- downloading repository index and all packages in it
- support incremental download with modified-since timestamp (or possibly compared to an old index)
- recreate repository index given index and list of directories where to look files from; create symlinks or hardlinks
- print list of package names present on indexv3.0Timo TeräsTimo Teräshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10874conversion of installeddb and query applets to new database format2023-01-31T11:16:53ZTimo Teräsconversion of installeddb and query applets to new database formatConvert all internal code to use the new ADB based structures.
Support old indexes by doing on-the-fly conversion.
Automatically convert and keep installeddb in the new format.Convert all internal code to use the new ADB based structures.
Support old indexes by doing on-the-fly conversion.
Automatically convert and keep installeddb in the new format.v3.1Timo TeräsTimo Teräshttps://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/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/10887feature to keep old/previous package when upgrading kernel2024-02-23T12:28:43ZNatanael Copafeature to keep old/previous package when upgrading kernelTwo problems:
- when kernel package is upgraded, modprobe will stop working til machine is rebooted, because old kernel modules were deleted.
- it would be nice to keep old kernel around for a while, in case new kernel is broken. For ex...Two problems:
- when kernel package is upgraded, modprobe will stop working til machine is rebooted, because old kernel modules were deleted.
- it would be nice to keep old kernel around for a while, in case new kernel is broken. For example as `/boot/vmlinuz-lts.old`
Possible solution:
We could have a virtual `.old` or `.previous` package. When flagged packages (`linux-lts`would have a flag of some sort) apk would on upgrade transfer ownership of the old package to this virtual package. Files that would be deleted are kept, and files that would be replaced could get a `.old` suffix.
The result would be that `/lib/modules/<old-version>` are transferred to virtual `linux-lts.old`, and `/boot/vmlinuz-lts` are kept as `/boot/vmlinuz-lts.old`. User can then chose to keep this til next time linux-lts is upgraded or for example clean up .old as last step during bootup. (for example `apk del '*.old'` or similar)
This way `modprobe` will continue work after an `apk upgrade` and user can have a vmlinuz-lts.old fallback in boot loader in case new kernel is broken.
Any package could be flagged with 'keep-old' but I think it mostly makes sense for linux kernels.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10891Add an option to download the packages before upgrading/installing packages2023-09-18T13:45:05ZBart RibbersAdd an option to download the packages before upgrading/installing packagesWhen running `apk upgrade` or `apk add` the packages are downloaded and installed 1-by-1. This means that if your internet connection for some reason drops out in the middle of it, you now have a partially upgraded system. It would be gr...When running `apk upgrade` or `apk add` the packages are downloaded and installed 1-by-1. This means that if your internet connection for some reason drops out in the middle of it, you now have a partially upgraded system. It would be great to have a command line switch or environment variable to tell apk to first download all packages it's modifying before installing them, so network failures halfway through don't leave you with a partially updated system.backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10892Fuzz apk-tools2024-02-23T12:54:00ZjvoisinFuzz apk-toolsIt would be nice to have some [fuzzing]( https://en.wikipedia.org/wiki/Fuzzing ) for apk-tools, since it's doing some cryptographic operations, has a lot of privileges, parses things coming from the internet, …
I would have done it myse...It would be nice to have some [fuzzing]( https://en.wikipedia.org/wiki/Fuzzing ) for apk-tools, since it's doing some cryptographic operations, has a lot of privileges, parses things coming from the internet, …
I would have done it myself, but since apk is using a database, it's non-trivial to write proper fuzzers :/backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10902`apk add --virtual` conflicts with tagged repositories2023-07-09T13:03:57ZDaniel Rudolf`apk add --virtual` conflicts with tagged repositoriesCurrently it's not possible to install a package from a tagged repository (`package@repository`) with a virtual package (`--virtual`/`-t`):
```
$ apk add --virtual .fetch-deps py3-pip@testing
ERROR: 'py3-pip@testing' is not a valid chil...Currently it's not possible to install a package from a tagged repository (`package@repository`) with a virtual package (`--virtual`/`-t`):
```
$ apk add --virtual .fetch-deps py3-pip@testing
ERROR: 'py3-pip@testing' is not a valid child dependency, format is name([<>~=]version)
```
It would be great if we can combine these two features.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10950`apk del --purge` does not delete "apk-new" files2023-12-01T08:44:54Zqaqland`apk del --purge` does not delete "apk-new" filesI have this package with its config in `/etc`:
```
miniflux.conf
miniflux.conf.apk-new
```
Now delete this package:
```
$ doas apk del --purge miniflux
(1/3) Purging miniflux-openrc (2.0.44-r3)
(2/3) Purging miniflux-doc (2.0.44-r3)
(...I have this package with its config in `/etc`:
```
miniflux.conf
miniflux.conf.apk-new
```
Now delete this package:
```
$ doas apk del --purge miniflux
(1/3) Purging miniflux-openrc (2.0.44-r3)
(2/3) Purging miniflux-doc (2.0.44-r3)
(3/3) Purging miniflux (2.0.44-r3)
Executing busybox-1.36.1-r4.trigger
Executing mandoc-apropos-1.14.6-r8.trigger
OK: 6501 MiB in 1077 packages
```
But still have this file left
```
miniflux.conf.apk-new
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10953Request to adopt and document an offical MIME Type2023-11-22T19:28:44ZvetsinRequest to adopt and document an offical MIME TypeIt can useful, specifically in the case of [SBOMs](https://cyclonedx.org/), to associate a MIME Type with a given package.
If we presume the file `aaudit-0.7.2-r2.apk` would be also represented as `pkg:apk/aaudit@0.7.2-r2` we would als...It can useful, specifically in the case of [SBOMs](https://cyclonedx.org/), to associate a MIME Type with a given package.
If we presume the file `aaudit-0.7.2-r2.apk` would be also represented as `pkg:apk/aaudit@0.7.2-r2` we would also want a mime-type to differentiate it from an Android package (e.g. `application/vnd.android.package-archive`).
I would suggest, according to [RFC-6838](https://datatracker.ietf.org/doc/html/rfc6838), `application/vnd.alpine.package-archive` or similar and it is [registered to the IANA](http://www.iana.org/assignments/media-types)
Some examples:
* deb is `application/vnd.debian.binary-package`
* rpm is `application/x-rpm`https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10956deferring chowns to unknown users until after triggers2024-01-09T09:05:37ZDaniel Kolesadeferring chowns to unknown users until after triggersI'm currently thinking of revamping the way users are handled. Ideally, I'd like to reduce usage of pre/post-install/upgrade/deinstall hooks as much as possible (the ideal amount being zero) in order to allow for fully atomic transaction...I'm currently thinking of revamping the way users are handled. Ideally, I'd like to reduce usage of pre/post-install/upgrade/deinstall hooks as much as possible (the ideal amount being zero) in order to allow for fully atomic transactions (hooks break that as they require the filesystem state to be updated). For users/groups, instead of doing it in hooks, I'd like some kind of central sysusers process (similar to systemd-sysusers) to take care of creation, and have it run from a trigger on the directory containing the configs.
Currently, user handling gets in the way of this. The apk files store ownership as usernames/groupnames, which is good as it allows uids/gids to be allocated dynamically. However, it also means that the user/group needs to exist in the passwd/group file so that it can be applied.
I gave this some thought, and had an idea - how about we simplify defer chowning the file to after triggers have completed running? Basically, every time the lookup fails, record the failure, then once triggers have run, retry the lookup and chown. Thoughts?https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10958apk3: a way to pin a package in place upon installation2023-12-15T17:08:47ZDaniel Kolesaapk3: a way to pin a package in place upon installationi'm currently trying to come up with a robust approach to handle kernel packages - i need old kernels to stick around so that people have something to revert to when updating - right now i'm having kernels have a pre-upgrade hook which b...i'm currently trying to come up with a robust approach to handle kernel packages - i need old kernels to stick around so that people have something to revert to when updating - right now i'm having kernels have a pre-upgrade hook which backs things up and then restores things in place afterwards, but i don't like this approach much (it breaks atomicity and isn't exactly robust)
so i considered the idea of versioning the pkgnames (i.e. instead of `linux-lts` the package name would be e.g. `linux-lts-6.6.6-0-generic` - this would ensure that a kernel update is just a new package to install, and pruning old kernels would not need a dedicated tool, but rather would be just standard package management
however, we currently have no way to actually pin the package in place after installation, so this is not implementable; it's not realistic to require users to add every kernel's explicitly versioned name into world, so maybe a feature could be added to aid this?
ideally we'd have a kernel package with a versioned name (e.g. `linux-lts-6.6.6-0-generic`) depended on by a package with an unversioned name (`linux-lts`); the unversioned name is what one would use for initial installation, and that would:
1) depend on the latest versioned name
1) that would somehow pin the versioned name in place
2) newer version of the kernel with same provider would result in a standard upgrade by the dependency being switched, however the old package would not get purged, and the new version would get pinned again (with its full versioned name)
3) purging old versions would be a simple `apk del`, with a full choice of what would get purged
there are probably other non-kernel cases where such mechanism would help too
or perhaps somebody has an idea how to implement this or equivalent mechanism without requiring new features?
ref https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10887https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10959simulate package count and size2024-01-15T16:22:49ZSertonixsimulate package count and sizeAfter running things like apk add/del/upgrade there is a summary of installed packages and the current size.
When simulating the installation the reals size and count is used instead of simulating it:
```
~ $ apk -s add sudo
...
OK: 665...After running things like apk add/del/upgrade there is a summary of installed packages and the current size.
When simulating the installation the reals size and count is used instead of simulating it:
```
~ $ apk -s add sudo
...
OK: 6652 MiB in 1435 packages
~ $ doas apk add sudo
...
OK: 6654 MiB in 1437 packages
```
I assume this could be fixed in [`src/commit.c#apk_solver_commit_changeset`](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/c8c9df1825760e558f44397500af2a2f4bca18d4/src/commit.c#L281).
The variable `size_diff` could be used to simulate the size correctly and the `changeset` for the amount of packages.
The verbose version also writes the files and dirs. I don't know if they can be simulated easily but if they can that would be nice too.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10960trigger on self deinstall2023-12-15T09:26:53ZSertonixtrigger on self deinstallIt would be nice to have the ability to run a trigger when the package providing the trigger is uninstalled.
This would allow trigger scripts to clean up the files they created. Eg. the mkinitfs trigger could remove the initramfs files....It would be nice to have the ability to run a trigger when the package providing the trigger is uninstalled.
This would allow trigger scripts to clean up the files they created. Eg. the mkinitfs trigger could remove the initramfs files.
The script would need to check for that case when it uses files provided by the package (eg. a command) since they won't be available in that case. To not break old scripts this could be implemented as an additional flag.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10963Parallel installation2024-02-23T12:34:40ZSander MaijersParallel installationSometimes a need for network I/O parallelism, for performance efficiency, can be avoided.
For example, repeated Alpine Linux-based container image builds can use a cache for `/var/cache/apk` across build runs.
However, installing appears...Sometimes a need for network I/O parallelism, for performance efficiency, can be avoided.
For example, repeated Alpine Linux-based container image builds can use a cache for `/var/cache/apk` across build runs.
However, installing appears to happen sequentially.
Since packages should not overlap on the filesystem, and their dependencies/integrity can be calculated, in principle, parallel installation must be possible.
On the other hand, package installation parallelism may have interactions with a transactional or more specifically atomicity-related architecturally significant requirements.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10964Provide development documentation2024-03-11T08:31:37ZSander MaijersProvide development documentation[`docs/`](docs/) contains user manuals, but short of that, development documentation seems absent.
@ariadne wrote interesting analyses such as https://ariadne.space/2021/10/31/spelunking-through-the-apk-tools-dependency-solver/, which I ...[`docs/`](docs/) contains user manuals, but short of that, development documentation seems absent.
@ariadne wrote interesting analyses such as https://ariadne.space/2021/10/31/spelunking-through-the-apk-tools-dependency-solver/, which I think deserve a more central place.
In addition, personally, I'd like to learn about `apk-tools`'s design principles and architectural requirements. For example, is `/var/cache/apk/` supposed to be data race safe in the face of parallel `apk` processes?backloghttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10972package version formatting2024-03-27T16:28:48ZSertonixpackage version formattingThe issue has mutated to a discussion about the version formatting in general.
Related !144, #7100, #10816
## Old description
The version format for virtual packages (`YYYYmmdd.HHMMSS`) doesn't include a `pkgrel` like packages normall...The issue has mutated to a discussion about the version formatting in general.
Related !144, #7100, #10816
## Old description
The version format for virtual packages (`YYYYmmdd.HHMMSS`) doesn't include a `pkgrel` like packages normally have (`<pkgver>-r<pkgrel>`).
This creates ambiguity in the output of the `apk list` command. Normally it is enough the strip the last 2 dashes but that doesn't work with the version format of virtual packages:
- `<pkgname>-<pkgver>-r<pkgrel>`
- `<pkgname>-YYYYmmdd.HHMMSS`
I suggest adding `-r0` to the version of virtual packages [`app_add.c#L118`](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/acefa1acc1ce0e1871d17b4eafe4b1888f45d4d0/src/app_add.c#L118). !132 does fix the `apk list` problem too but a consistent version format would still be better.v3.0https://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/10985can't read --protected-paths from pipe2024-03-25T10:06:54ZSertonixcan't read --protected-paths from pipe`apk audit --protected-paths /dev/stdin` doesn't read stdin at all.
The reason seems to be that the `apk_blob_from_file` function doesn't handle pipes/fifos.`apk audit --protected-paths /dev/stdin` doesn't read stdin at all.
The reason seems to be that the `apk_blob_from_file` function doesn't handle pipes/fifos.https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10987apk3 fails to parse apk2 install_if2024-03-27T15:36:33ZSertonixapk3 fails to parse apk2 install_ifWhen I run `apk3 -s upgrade` on an apk2 system I get false package installation:
```
~/src/apk-tools$ output/src/apk -s upgrade
(1/4) Installing opensmtpd-openrc (7.4.0p1-r1)
(2/4) Installing opensmtpd-doc (7.4.0p1-r1)
(3/4) Installing o...When I run `apk3 -s upgrade` on an apk2 system I get false package installation:
```
~/src/apk-tools$ output/src/apk -s upgrade
(1/4) Installing opensmtpd-openrc (7.4.0p1-r1)
(2/4) Installing opensmtpd-doc (7.4.0p1-r1)
(3/4) Installing owfs-doc (3.2p4-r0)
(4/4) Installing tcptraceroute-doc (1.5b7-r4)
OK: 4855 MiB in 1366 packages
```
apk2:
```
~$ apk -s upgrade
OK: 4855 MiB in 1366 packages
```
It seems that apk3 doesn't parse the install_if field correctly in apk2 packages:
```
~/src/apk-tools$ output/src/apk info tcptraceroute-doc --install-if
tcptraceroute-doc-1.5b7-r4 has auto-install rule:
docs
```
apk2:
```
~$ apk info tcptraceroute-doc --install-if
tcptraceroute-doc-1.5b7-r4 has auto-install rule:
docs
tcptraceroute=1.5b7-r4
```
This may be related to the still undocumented `digit{letter{digit}}` format used on alpine linux (https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10972#note_380899).https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10988should provider format allow `,` and `[`2024-03-27T14:51:23ZSertonixshould provider format allow `,` and `[`alpine linux includes providers that don't follow the current spec since they contain `,` and `[` characters. The question is if they should be allowed or excluded as providers.
```
cmd:[
cmd:sxmo_deviceprofile_fairphone,fp4.sh
cmd:sxmo...alpine linux includes providers that don't follow the current spec since they contain `,` and `[` characters. The question is if they should be allowed or excluded as providers.
```
cmd:[
cmd:sxmo_deviceprofile_fairphone,fp4.sh
cmd:sxmo_deviceprofile_kobo,clarahd.sh
cmd:sxmo_deviceprofile_lge,hammerhead.sh
cmd:sxmo_deviceprofile_longcheer,l8150.sh
cmd:sxmo_deviceprofile_motorola,harpia.sh
cmd:sxmo_deviceprofile_nokia,omap3-n900.sh
cmd:sxmo_deviceprofile_oneplus,cheeseburger.sh
cmd:sxmo_deviceprofile_oneplus,dumpling.sh
cmd:sxmo_deviceprofile_oneplus,enchilada.sh
cmd:sxmo_deviceprofile_oneplus,fajita.sh
cmd:sxmo_deviceprofile_pine64,pinebook-pro.sh
cmd:sxmo_deviceprofile_pine64,pinebook.sh
cmd:sxmo_deviceprofile_pine64,pinenote.sh
cmd:sxmo_deviceprofile_pine64,pinephone-1.0.sh
cmd:sxmo_deviceprofile_pine64,pinephone-1.1.sh
cmd:sxmo_deviceprofile_pine64,pinephone-1.2.sh
cmd:sxmo_deviceprofile_pine64,pinephone-pro.sh
cmd:sxmo_deviceprofile_pine64,rockpro64-v2.1.sh
cmd:sxmo_deviceprofile_purism,librem5r2.sh
cmd:sxmo_deviceprofile_purism,librem5r3.sh
cmd:sxmo_deviceprofile_purism,librem5r4.sh
cmd:sxmo_deviceprofile_qcom,msm8226-mtp.sh
cmd:sxmo_deviceprofile_samsung,a3u-eur.sh
cmd:sxmo_deviceprofile_samsung,a5u-eur.sh
cmd:sxmo_deviceprofile_samsung,coreprimevelte.sh
cmd:sxmo_deviceprofile_samsung,e5.sh
cmd:sxmo_deviceprofile_samsung,e7.sh
cmd:sxmo_deviceprofile_samsung,grandmax.sh
cmd:sxmo_deviceprofile_samsung,gt510.sh
cmd:sxmo_deviceprofile_samsung,i9300.sh
cmd:sxmo_deviceprofile_samsung,j5.sh
cmd:sxmo_deviceprofile_samsung,j5x.sh
cmd:sxmo_deviceprofile_samsung,n8010.sh
cmd:sxmo_deviceprofile_shift,axolotl.sh
cmd:sxmo_deviceprofile_wingtech,wt88047.sh
cmd:sxmo_deviceprofile_xiaomi,beryllium.sh
cmd:sxmo_deviceprofile_xiaomi,elish.sh
cmd:sxmo_deviceprofile_xiaomi,polaris.sh
cmd:uutils-[
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10989Question: About apk-tools-zsh-completion2024-03-27T23:37:17ZMalik NQuestion: About apk-tools-zsh-completionIt seems I have a package called apk-tools-zsh-completion, but I cant find it in the world file, not with `whereis apk-tools-zsh-completion`, and not in the aports repository. It is only visible in gnome software with the same version nu...It seems I have a package called apk-tools-zsh-completion, but I cant find it in the world file, not with `whereis apk-tools-zsh-completion`, and not in the aports repository. It is only visible in gnome software with the same version number like apk-tools 2.14.1.
What might have caused this and how I can source those files in my .zshrc?