I have no idea, your guess is as good as mine. Sorry for pointing out a potential issue whilst not providing a good solution =(
It does get a little long haha.
I'm still thinking of a good way to draw users in to read. Opkg going away for next release seems like a good draw but eh.
another edit:
Also of note. At least for me it's now gone from the latest in the release and announcements category, when browsing categories, even though it's pinned.
In my opinion, APK v3 using "adb" instead of tar is a regression. Now the only way to parse apk files is to install apk-tools? What is the need to reinvent an archive format?
How can I add an additional configuration file directory to the apk command (like /etc/opkg/)？So that I can add third-party software sources and avoid being reset during upgrades. And how can I specify the packages.adb cache directory (like "lists_dir ext" in opkg.conf)?
I'm having an interesting issue, on clean build snapshot, from firmware selector (SNAPSHOT r28085-6720c4ccba) I got the following.
root@mt6000:/etc/apk# apk update
fetch https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/packages/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/packages/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/base/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/base/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/kmods/6.6.60-1-0561031e21f60f05c8f540bffb723036/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/kmods/6.6.60-1-0561031e21f60f05c8f540bffb723036/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/luci/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/luci/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/packages/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/packages/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/routing/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/routing/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/telephony/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/telephony/packages.adb: No such file or directory
7 unavailable, 0 stale; 275 distinct packages available
sounds like either a network problem, some problem with the download tools in router, or a bad timing if buildbot has just been uploading its new build.
Right e.g. that one .adb is there and can be downloaded
@ka2107 Can the 'arch' be read from an additional file (/etc/apk/arch.d?). I might add repositories for more generic architectures, for example aarch64_generic repositories for aarch64_cortex-a53 devices
There has never been any discussion of apt on OpenWrt that I've seen. apk was chosen due to its high functionality:size ratio, which is not a surprise coming from the Alpine Linux distro where, like OpenWrt, size is also a primary concern.
Except that this isn't a 'bug', but -for better or worse- a design decision of the apk v3 package format and 'unchangeable' for the time being, therefore inactionable. If the OP wants to influence future apk v4+ design decisions, they will need to participate in its development, providing patches/ code and make well founded arguments, not drive-by bugreports to annoy its developers.
Don't get me wrong, there are advantages in reusing well-known tools to dissect packages, but apk's upstream might have had a reason to go a different route - and dismissing them off-hand is not exactly a productive approach.
