Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add metapackage for bootstrap environment #22140

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

sylirre
Copy link
Member

@sylirre sylirre commented Nov 6, 2024

Closes #22127

@robertkirkman
Copy link
Contributor

robertkirkman commented Nov 6, 2024

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.

@agnostic-apollo
Copy link
Member

agnostic-apollo commented Nov 6, 2024

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.

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.

@robertkirkman
Copy link
Contributor

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.

@agnostic-apollo
Copy link
Member

agnostic-apollo commented Nov 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: Preinstalled packages all marked as manually installed
3 participants