It should be noted that there is also a build-bootstraps.sh with a similar construction as well as a generate-bootstraps.sh. however, it should also be noted that there are some problems with the current build-bootstraps.sh, and termux-play-store has solved them by deleting its build-bootstraps.sh and making its generate-bootstraps.sh compatible with building packages optionally. That means that if the plan is to eventually implement a similar rework to generate-bootstraps.sh in this repository also, then build-bootstraps.sh could be ignored for now until it is deleted later.

This is not gonna help with not listing a "gazillion" packages on fresh install. apt list --installed will still show all packages. Secondly, this would also not mark the dependencies of termux-bootstrap package as automatic, as that state is stored in $PREFIX/var/lib/apt/extended_states, which neither bootstraps add to. You would then have to process which recursive dependencies belong to termux-bootstrap and also were not added due to execution variant or passed as additional packages to bootstrap scripts.

• https://unix.stackexchange.com/a/360705

Hardocding such a dependency list would also mean that forked would have to manually patch the build.sh file if they don't want to add specific packages to bootstraps, instead of being able to dynamically specify packages to add/exclude with command line options when calling bootstrap scripts in some action runner, etc.

Both generate and build bootstrap scripts have been rewritten locally and (do support all such options), but not complete, as being blocked currently by other changes, like repo and library changes. Hopefully should be complete in a month or so depending on priorities.

It should be noted that the same logic also applies to forks of Arch Linux, where creators of forks of Arch Linux who want to remove packages from the minimal install must either edit the base package, or remove the reference to it and install each package individually instead. It ends up being an organization preference with pros and cons both ways. Since there is not currently a command line argument that allows "excluding" packages from the bootstrap, at least right now, a fork creator has to manually modify a file somewhere to remove any base packages, either way. On the other hand it is completely true that to mark the packages as automatic in apt list-installed, to make it convenient to filter them, Auto-Installed: 1 must be inserted into $PREFIX/var/lib/apt/extended_states by the script anywhere appropriate.

It's not just forks, there are multiple execution types and not all packages are added for each and we would then need to add multiple virtual packages build.sh files for each execution type. It would be much simpler to mark all packages added to bootstrap that are dynamically selected to be automatic, and then manually adding a virtual package control entry to dpkg/status file which lists all bootstrap packages added as dependencies, instead of us maintaining multiple build.sh files. Any forkers would then only need to modify one file if they want to change default packages or just add/exclude packages with command line options without patching any file. I can make these changes myself, may need to think more on it. An issue might be that users may not be able to uninstall any of those packages if they are dependencies of a virtual essential package.