I'd appreciate some suggestions for the restore script.
I do not recall how far I got with it, but it isn't yet fully implemented.

Notably, the way we'd want to handle keeping the old versions of the packages in the PR around hasn't been hashed out yet, and the script isn't currently being installed as part of the apt package.

Personally, if the decision were up to me, I would prefer to treat apt 3.0+ as a normal rolling-release package upgrade and not include a "rollback script", which is (in my opinion) not idiomatic to the general philosophy of rolling-release distributions.

In other rolling-release distributions, there is an expectation that, if users do not already know how, but encounter any unfixable problem with the new package versions, users should learn how to manually build old packages on another system and perform the rollback manually by transferring and force-reinstalling the old package versions in order to fix their broken environment.

There have been many instances throughout history when a broken pacman has occurred for almost the entire user base of Arch Linux, and it has been necessary for users of Arch Linux to manually retrieve and force-reinstall an older pacman to recover.

I'm also not sure myself how to safely implement a "fully automated" rollback script of this kind in any rolling-release distribution, because, since the exact versions of dependencies in rolling-release distributions are never locked to any "baseline release" set of package versions that could be expected, it is, as far as I know, impossible to predict exactly what dependency-related errors will occur for any given user when force-reinstalling older package versions, and that is something that users just have to figure out on their own using standard problem-solving steps for rolling-release distributions.

However, if the decision is not up to me, then I would be happy to test any rollback script prototype on my devices once it is ready to run, and report the results, so that it could at least be a rollback script that has consistent and possibly-useful behavior, even if it's not possible for it to handle every single edge case that could occur.

Notably, the way we'd want to handle keeping the old versions of the packages in the PR around hasn't been hashed out yet

Arch Linux has an archive for all older packages of all older versions released anytime in the last several months or years.

That is actually part of Arch Linux's official wiki page documenting how to downgrade packages in Arch Linux.

however, the important reason that works in Arch Linux is because they actually store an archive of all their packages, not just a few, and unlike Debian sid and Termux, they don't delete old packages arbitrarily, but have many old packages in their archive going back a really long time.

That makes it simple for Arch Linux users to perform the process of manually rolling back packages and all their dependencies, since they can try the package first -> if the package at the version they need reports a runtime error because of incorrect dependencies, they can go find the dependencies at the needed versions in the package archive -> repeat,

The equivalent steps in Termux (since Termux does not archive all old packages) are:

• to first download two clones of the termux-packages git repository
• use git checkout to rollback one of the clones to the last commit that contained the desired package(s)
• manually override the latest-clone with the needed packages copied and pasted from the rolled-back clone
• build all of the desired old package versions using the scripts folder and other packages present in the latest-clone
• and then transfer the newly-rebuilt old package versions to the Termux device where they are needed, and manually reinstall them there,
• repeat until no more errors

Additionally skill set of average arch users and Termux users would be slightly different ;)

Additionally skill set of average arch users and Termux users would be slightly different ;)

I agree, but part of my point is that fully-automated rollback scripts that handle every single possible edge-case are, as far as I know, impossible to implement in rolling-release distributions because of properties shared between all rolling-release distributions, so unless a "termux-packages 'release' package set for last apt 2.X" is made and fully backed up so that it can be treated as the "stable reference point" for rolling-back to (simulating/implementing the effects of a non-rolling-release distro), it might be impossible for users encountering any hypothetical issue with the apt package (or any other package bump, since the same considerations technically apply for any upgrade of any package in rolling-release distributions) to fix their issue without learning the troubleshooting and recovery steps that are shared between all rolling-release distributions.

We do publish bootstraps which contain all dependencies of apt at snapshots confirmed to work going back for quite a while, here:

https://github.com/termux/termux-packages/releases

If a rollback script is important, maybe one of these could be selected and used as the download from which the script could extract and install a working copy of apt 2.X and its dependencies?

There could be other problems with that approach, but it's one idea since the bootstraps might represent functioning "releases" of all the necessary components to run apt 2.X (just not, unlike real non-rolling-release distros, any other packages that are not already included in the bootstraps, which could easily result in any non-bootstrap packages the user has installed becoming broken after the rollback, but maybe if the goal is recovery of apt alone, those aren't as important in the opinion of some - in my opinion, preserving the functionality of all other packages the user has installed is important, but others might disagree).

TL;DR of all I wrote is, that in my opinion, a "rollback script" in Termux is unlikely to work reliably and could easily cause more problems than it fixes, in a cascading whack-a-mole effect that the more hypothetical errors it attempts to fix, the more errors are likely to appear. Others might have other opinions.

Extracting package and dependencies from bootstraps would be too much work as they would exist as a prefix directory. It might be possible to create a pool-archive directory on the repo with all the required debs for apt and recursive dependencies that "currently exist", that state is currently working, that should be enough to restore, without running into dependency linking issues. It could break other packages that may rely on newer dependencies, but we could fix the apt 3.0 issue that was found and release an update, after which users could upgrade all packages using apt 2.0 to get all packages working.

The goal should be to provide a reasonable/basic recovery mechanism, not cater to every possibly scenario. The emergency-restore.sh.in looks fine from a quick look, would have to check it more closely and ensure all dependencies are restored, etc and change url to pool-archive, etc.

I have discovered that NDK r29

• scripts(toolchain): Update NDK to r29 #27089

appears that it will cause this patch to not be necessary anymore