APK v3

henderkes

When trying to connect an alpine client (3.20+) to a ProGet apk repo, you get errors about the unsupported v2 format of the repo. Alpine 3.20+ only supports v3, while <=3.19 support both v2 and v3.

rhessinger

Hi @henderkes,

Based on the Alpine's Package Keeper documentation, although the apk-tools are at version 3, the index and packages are still v2. From what I can tell, there is no timeline on when the v2 Index format will be dropped and the use of the v3 index is an opt-in feature. Currently ProGet only supports the v2 index and package format. I have added apk V3 support to be reviewed for ProGet 2026.

Could you please provide a little more details around what operations are giving you the errors and the log output that shows the error?

Thanks,
Rich

henderkes

@rhessinger Hi, thanks for the quick response. I set up an Alpine repo on ProGet and uploaded one package to it. Set up docker with alpine:latest and alpine:3.20 and both times got a message about v2 formats not being supported any longer when trying to apk add php-zts-cli.

Additionally, if I add more than one package to the repository, on 3.19, apk only sees the first uploaded package to a feed. If I use native builds on the other hand, apk works on :latest too and finds all packages.

I'll post exact replication instructions and share the packages in question later.

henderkes

Alright here we go. First issue: trying to use the endpoint that proget advertises:

for file in *; do
curl http://localhost:8624/apk/alpine-test/ --user Admin:Admin --upload-file "$file"
done

Results in Endpoint not available at this url.. The correct url does not have a trailing slash, I'm not sure why proget advertises it with one.

After uploading correctly, we can run a Docker container:

[m@M m]$ docker run -it --network host alpine:latest sh
/ # apk add wget nano curl
wget -O "/etc/apk/keys/alpine-test@proget.rsa.pub" http://localhost:8624/apk/alpine-test/keys/alpine-test%40proget.rsa.pub
echo "http://localhost:8624/apk/alpine-test/" >> /etc/apk/repositories
/ # apk add php-zts85-cli
WARNING: opening from cache http://localhost:8624/apk/alpine-test/x86_64/APKINDEX.tar.gz: v2 database format error
ERROR: unable to select packages:
  php-zts85-cli (no such package):
    required by: world[php-zts85-cli]

This shows the aforementioned v2 database format error.

Switching to alpine 3.19 instead we get this:

[m@M m]$ docker run -it --network host alpine:3.19 sh
/ # apk add wget nano curl
wget -O "/etc/apk/keys/alpine-test@proget.rsa.pub" http://localhost:8624/apk/alpine-test/keys/alpine-test%40proget.rsa.pub
echo "http://localhost:8624/apk/alpine-test/" >> /etc/apk/repositories
/ # apk add php-zts85-cli
/ # apk add php-zts-cli
fetch http://localhost:8624/apk/alpine-test/x86_64/APKINDEX.tar.gz
ERROR: unable to select packages:
  php-zts-cli (no such package):
    required by: world[php-zts-cli]
/ # apk add php-zts85-cli
(1/1) Installing php-zts85-cli (8.5.1-r1)
Executing busybox-1.36.1-r20.trigger
ERROR: Metadata for package php-zts85-cli-8.5.1-r1 is too long.
OK: 44 MiB in 27 packages
/ # apk add php-zts85-xdebug
ERROR: unable to select packages:
  php-zts85-xdebug (no such package):
    required by: world[php-zts85-xdebug]
/ # apk add php-zts85-embed
ERROR: unable to select packages:
  php-zts85-embed (no such package):
    required by: world[php-zts85-embed]
/ # apk search php-zts*
php-zts85-cli-8.5.1-r1
/ # wget -qO- http://localhost:8624/apk/alpine-test/x86_64/APKINDEX.tar.gz | tar -xzOf - APKINDEX
C:jnSWoXlvdzJ48vsZpcYhEAaZj9M=
P:php-zts85-cli
V:8.5.1-r1
A:x86_64
S:12748469
I:32503398
T:Static PHP Package for php-zts85-cli
U:https://apks.henderkes.com
L:PHP-3.01
m:Marc Henderkes <apks@henderkes.com>
p:php-zts85 php-zts85-calendar php-zts85-ctype php-zts85-curl php-zts85-dom php-zts85-exif php-zts85-filter php-zts85-iconv php-zts85-libxml php-zts85-mbregex php-zts85-mbstring php-zts85-opcache php-zts85-openssl php-zts85-password-argon2 php-zts85-pcntl php-zts85-phar php-zts85-posix php-zts85-readline php-zts85-session php-zts85-simplexml php-zts85-sockets php-zts85-sodium php-zts85-tokenizer php-zts85-xml php-zts85-xmlreader php-zts85-xmlwriter php-zts85-zlib

C:svJ58ZEKUidf2ck76iqaT4HGoN8=
P:php-zts85-embed
V:8.5.1-r1
A:x86_64
S:418
I:0
T:Static PHP Package for php-zts85-embed
U:https://apks.henderkes.com
L:PHP-3.01
m:Marc Henderkes <apks@henderkes.com>
D:php-zts85-cli>=8.5 php-zts85-cli<8.6 php-zts85-cli
p:libphp-zts85-85.so php-zts85-embedded

C:fqDCNefOnm61ZJSVuTAW6GSrRDk=
P:php-zts85-xdebug
V:3.5.0-r1
A:x86_64
S:231512
I:511135
T:Static PHP Package for php-zts85-xdebug
U:https://apks.henderkes.com
L:Xdebug-1.03
m:Marc Henderkes <apks@henderkes.com>
D:php-zts85-cli>=8.5 php-zts85-cli<8.6 php-zts85-cli

as you can see, the apkindex does exist and advertises the different packages, but apk doesn't see them and I can't install them.

When I use my own repository (not public atm) or a cloudsmith testing repository, everything works as expected:

[m@M m]$ docker run -it --network host alpine:latest sh
/ # apk add curl sudo bash wget nano
/ # curl -1sLf 'https://dl.cloudsmith.io/public/static-php/alpine-test/setup.alpine.sh' | sudo codename=any-version -E b
ash
Executing the  setup script for the 'static-php/alpine-test' repository ...

   OK: Checking for required executable 'curl' ...
   OK: Detecting your OS distribution and release using system methods ...
 ^^^^: ... Detected/provided for your OS/distribution, version and architecture:
 >>>>:
 >>>>: ... distro=alpine  version=3.23.0  codename=any-version  arch=x86_64
 >>>>:
   OK: Importing 'static-php/alpine-test' repository RSA key...
   OK: Checking if upstream install config is OK ...
   OK: Installing 'static-php/alpine-test' repository...
   OK: Updating alpine repository metadata cache ...
   OK: The repository has been installed successfully - You're ready to rock!

/ # apk add php-zts85-cli
(1/1) Installing php-zts85-cli (8.5.1-r1)
Executing busybox-1.37.0-r29.trigger
OK: 29 MiB in 35 packages
/ # php-zts85 -v
PHP 8.5.1 (cli) (built: Dec 20 2025 22:44:31) (ZTS zig 0.16.0-dev.1484+d0ba6642b x86_64)
Copyright (c) The PHP Group
Built by Static PHP <https://static-php.dev> #StandWithUkraine
Zend Engine v4.5.1, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.1, Copyright (c), by Zend Technologies
/ # apk add php-zts85-xdebug
(1/1) Installing php-zts85-xdebug (3.5.0-r1)
OK: 30 MiB in 36 packages
/ # php-zts85 -v
PHP 8.5.1 (cli) (built: Dec 20 2025 22:44:31) (ZTS zig 0.16.0-dev.1484+d0ba6642b x86_64)
Copyright (c) The PHP Group
Built by Static PHP <https://static-php.dev> #StandWithUkraine
Zend Engine v4.5.1, Copyright (c) Zend Technologies
    with Xdebug v3.5.0, Copyright (c) 2002-2025, by Derick Rethans
    with Zend OPcache v8.5.1, Copyright (c), by Zend Technologies

rhessinger

Hi @henderkes,

Thank you for sending all this over! We are going to dig into this a bit further and will let you know what we find.

Thanks,
Rich

rhessinger

Hi @henderkes,

Can you provide where you are getting your test packages from? I have a feeling it has to do with them more than the index. I setup the environment you specified with alpine packages I pulled from Zend PHP and had no issues. I was able to update the index and install multiple packages.

Thanks,
Rich

henderkes

Hi, you can get the packages from the codesmith repo I set up. They're still available there.

I've also tried with two test packages containing just hello.txt and world.txt and got the same results.

Running inedo with Docker, if it matters!

rhessinger

Hi @henderkes,

I did try to download that script to extract the repo you were referring to, but Alpine does not have bash installed, only ash, so I get an error when attempting to run it. Could you please provide me a direct link? To be honest, this all screams a configuration error on Alpine or an issue with the APK directly.

In my test, I created a feed in ProGet with a connector created pointing to "https://repos.zend.com/zendphp/apk_alpine320/x86_64/". I then added my feed to alpine, apk update, and then apk add php85zend. Everything worked as expected.

Thanks,
Rich

henderkes

@rhessinger You can install bash on alpine too. You can get a direct download to the packages here: https://pkg.henderkes.com/85/php-zts/packages?q=&type=alpine

For testing it should be enough to download php-zts-cli and php-zts-zstd.

If connected feeds are working for you, the issue may be specific to local feeds.

rhessinger

Hi @henderkes,

Thanks for sending those packages over. I was able to recreate some issues with those packages and we are currently still looking for the cause. I'll send over an update once I have a bit more information.

Thanks,
Rich

rhessinger

Hi @henderkes,

Sorry for the delay on this. Right now, there looks to be a couple issues I'm working through with this. I should have an update for you on Friday. I believe I have identified the issues, but I'm trying to confirm some things based on your APK packages. Just to confirm, the packages you shared are APK Tools V2 packages correct?

Thanks,
Rich

rhessinger

Hi @henderkes,

So we have identified the issue. When it comes to your packages, there where two issues that were preventing them from being updated and installed.

The packages you provided to me are unsigned. According to the APK documentation, that is not supported. In reality, that is a case that they support and have supported for some time. So we have a ticket, PG-3192, to correct the checksum generation for unsigned packages.
When a checksum is not generated, ProGet was inserting the hash of the package instead, which would cause the index to fail.
- In older versions of APK tools V2, this would fail the install of that package, but show you the all packages in the index.
- In newer versions of APK Tools V2, it will stop processing once a package with a bad checksum is shown. Which is why it looked like only one package existed in the feed. Installing these packages will most likely fail with a checksum error.
- In APK Tools v3, it errors on apk update and these packages cannot be installed at all.

We are going to be adding the checksum verification to the Feed integrity checks and a way to regenerate the checksums in ticket PG-3193. That should resolve all these issues for you. That also explains why my test cases worked fine, because most public index packages are signed packages.

Thanks,
Rich

henderkes

@rhessinger Oh, that explains it. I deliberately left all packages unsigned as I expected ProGet to sign them for me instead. Thank you for figuring this out!

rhessinger

Hi @henderkes,

No problem! Both these issues are expected to be fixed in this Friday's release of ProGet 2025.18.

Thanks,
Rich