apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2022-12-21T18:50:51Zhttps://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.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/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/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/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/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/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.1