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 officially supported Arch Linux version Termux (Build flavor) #2176

Closed
stevenleeS0ht opened this issue Jul 18, 2021 · 2 comments
Closed

Comments

@stevenleeS0ht
Copy link

Currently, There is some unofficial support for archlinux on Termux.

But it is a little bit buggy and take a lot of time to setup.

And the repo of Arch variant of Termux is usually from ArchLinux ARM.

Since Termux use build.sh and Arch use PKGBUILD , both of them are shell script and have similar structure and procedure flow.

As a result, write a program to mapping the build.sh to PKGBUILD (just change the function name) won't be difficult.

And then use makepkg of pacman to build according to the generated PKGBUILD file.

Because a lot of computer hackers and geeks use Arch Linux, and Termux is intend for hackers and geeks.

As a result, add official support on Arch Linux would make Termux more popular.

@stevenleeS0ht
Copy link
Author

@fornwall , is this realistic?

@ghost
Copy link

ghost commented Jul 18, 2021

is this realistic

Will be realistic as soon as everyone of our dev team will consider current approach with our build system flawed and non-viable for support in future. Package manager change is possible, but pointless and will require to shut down existing apt repositories in order to free space for the new ones.

If you are talking about using Arch distro as Termux base, then this becomes problematic:

  • Libc and toolchain. Those needs to be patched, so programs can run in Termux natively without proot. There is a one simple question: who will maintain that? - That's a question for which I always ask when a custom libc or related stuff is requested. Never got an answer.
  • Rootfs. We have choices: prefix like in current implementation or proot. Each has pros and cons. Proot is not stable, applies some performace penalty and doesn't resolve all issues with rootless chroot. Though it has potential to resolve Revisit the Android W^X problem #2155, can be used to run software from normal Linux distributions, etc.

- These are only basic issues to consider. Typicaly there are more. For example, in case of porting Arch to Termux, we will have troubles with package hosting, Arch repositories are too big. And again, who will maintain all of that? Termux dev team is small and does not work on project on a regular basis.

Do you think that presence of makepkg will resolve all possible issues with compilation? Nope, if Termux will not change its base. Most of software compilation issues arise from use of NDK system root instead of traditional GNU libc and Linux headers.

https://github.com/termux/termux-packages has support for building packages on device, if you need a way for making custom packages.

There is UserLAnd which accomplishes your request (use Arch as environment). So why Termux should become its clone? It will be literally same, with few application interface differences.

Just for note, Termux is a terminal emulator application with extra packages.

As a result, add official support on Arch Linux would make Termux more popular.

If Termux will use Arch packages, it won't receive official Arch support anyway. Packages are needed to be either executed under proot or patched for Anroid NDK and prefix. Don't forget that official Arch is x86_64 and for ARM you will always need to use fork ArchLinuxARM.

In other words, it always be a little bit buggy or take a lot of time to setup.

@ghost ghost added the discussion label Jul 18, 2021
@ghost ghost closed this as completed Jul 25, 2021
@ghost ghost removed the discussion label Jul 25, 2021
This issue was closed.
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

No branches or pull requests

1 participant