alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2022-12-21T19:39:44Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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.1