apk-tools issueshttps://gitlab.alpinelinux.org/alpine/apk-tools/-/issues2022-12-21T19:37:22Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/1241