alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2019-12-27T14:52:15Zhttps://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/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/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/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/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/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/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.0