rmpkg(main/tsu): replaced with agnostic-apollo sudo

[robertkirkman]

• Closes tsu doesnot work #25858

• Closes Package tsu need fix affected by magisk #24820

• Closes [Bug]: tsu Not Able to Run Certain Commands #18383

• Closes [Bug]: Running tsu gives me the Current Working Directory with (unreachable) prfixed #8184

• agnostic-apollo's sudo replaces this package:

termux-packages/packages/sudo/build.sh

Line 13 in d601524

TERMUX_PKG_REPLACES="tsu"

• This software is unfortunately not maintained for a while and began to accumulate some issues. The most important issues are already fixed or not present in the sudo package.

• More information:

  • Update tsu's magisk-su.patch for new version of Magisk #24684
  • use su -s instead of -c for getting interactive shell cswl/tsu#116
  • [Bug]: tsu not working. termux-app#4612
  • Termux tsu reported error with Magisk_28104 topjohnwu/Magisk#9003

[robertkirkman]

The removal of tsu might cause confusion or disruption for some users who might need it for a legacy reason.

For that reason, I intend to wait a long time and hopefully collect feedback on the advisability of removing tsu before merging this.

A similar removal of a termux-specific command in the past unfortunately caused a disruption,

#24224 (comment)

so I think it is best to leave this open for a long time so that users still depending on tsu can have time to find this and read about it.

[agnostic-apollo]

Yes, likely will break user scripts using tsu. Could maybe provide tsu wrapper script that calls apollo's sudo instead, would have to look into command options supported by tsu.

[robertkirkman]

BayonetArch believes that it's time to remove tsu and that people probably don't need arguments that are perfectly compatible with the arguments of the old tsu since sudo has replacement arguments that do similar things, like sudo -a bash and sudo -T su. I think that I agree, and tsu should be removed soon. I am still afraid that someone might get upset about it, but I hope that they can be satisfied if shown the replacement command and its arguments.

[agnostic-apollo]

Our approach will really depend on what the goal is. Do we want no new users to be able to install tsu or we still want to support some legacy mechanism for users to still be able to install tsu if they really need it for old projects. For the later, we can rename the package to tsu-legacy or something, I don't know the what the dpkg/apt convention is for that.

[robertkirkman]

Do we want no new users to be able to install tsu

I think this is the goal, in order to help migrate people away from it who have been encountering problems with it and opening issues here for it.

we still want to support some legacy mechanism for users to still be able to install tsu if they really need it for old projects.

I would consider "download the termux-packages repository, manually move the package folder from disabled-packages to packages, then manually rebuild it and reinstall it using on-device building" to be that mechanism,

but I seem to find that a lot less inconvenient than some other people do, so I might be biased on that topic. To really know the answer to that, it would be necessary to find someone who still wants to use tsu and isn't satisfied with the sudo package, and find out what they prefer.

The user closest matching that description I think I can remember seeing is @yujincheng08.

yujincheng08, if you are still using a local build of tsu for your personal use, do you think removing it from pkg install and making it require the use of build-package.sh to get is fine with you?

[agnostic-apollo]

opening issues here for it.

They will still open issues for tau package not found errors though.

Moving it to disabled packages can be done, but manual builds are not feasible for the general population. Maybe we can make a post on reddit and matrix that we are removing tsu package, and if enough people still want it to be available in repo, they can say now so that we rename it to tsu-legacy instead.

manually move the package folder from disabled-packages to packages

You don't need to do this, -D flag can be passed to build-package.sh

[robertkirkman]

Maybe we can make a post on reddit and matrix that we are removing tsu package, and if enough people still want it to be available in repo, they can say now so that we rename it to tsu-legacy instead.

sure, that sounds like a good idea. However, I don't personally use Reddit, so I would not be able to make the announcement there.

You don't need to do this, -D flag can be passed to build-package.sh

It is correct that that is the intended method, however, unfortunately, a long time ago (approximately 1 year ago, I think), I encountered a build error with that method that did not occur when I moved the folder manually, so I got into the habit of doing it the other way.

I don't remember what the error or package exactly was, but I'll try to remember to start using -D again the next time I need to build a disabled-package, and check to see if the error ever happens again so that it can be fixed.

[agnostic-apollo]

I can make posts, but likely tomorrow.

Yeah, report when you find them, there are changes for disabled packages folders in my repo.json changes pull too.

[yujincheng08]

The user closest matching that description I think I can remember seeing is @yujincheng08.

yujincheng08, if you are still using a local build of tsu for your personal use, do you think removing it from pkg install and making it require the use of build-package.sh to get is fine with you?

I am a developer of Magisk, and we are writing a sudo for Magisk, so I support removing it.

[robertkirkman]

Yeah, report when you find them, there are changes for disabled packages folders in my repo.json changes pull too.

I have opened an issue to track and document the problem as it exists in the master branch here,

• [Bug]: -D argument to build-package.sh does not work #25945

in a while, I might also try to test the same steps in your PR branch, to see if it's able to fix the problem.

[agnostic-apollo]

Made a post about this at https://www.reddit.com/r/termux/s/x7PsC5xCcu

[robertkirkman]

I agree with everything said there, except that one suggestion I would make is: in the event that someone makes a request to keep providing tsu because they need it, I think that instead of renaming the package to tsu-legacy, a clearer and more helpful way to inform users that the package is no longer supported would be to put a message in echo or printf commands in the postinst script of the package that explains that the package is no longer supported and that pkg install sudo can provide the replacement. This is just a suggestion and, if you prefer just renaming the package, or prefer to do both options at once, then that is also ok.

The recommendations of whichever person hypothetically asks for it would be important to consider as well, since they would be the only remaining user.

[agnostic-apollo]

I don't think most users would read postinst messages, especially for package updates due to long logs, even I don't.

[robertkirkman]

I must be the exception. It might be a habit I have because not carefully reading the package update logs of the distros I have historically used the most, Debian sid, Arch Linux and Gentoo, can sometimes lead to a broken installation.

In those distros, though, the amount of things that can go wrong, and how badly the OS can be broken, is much greater than Termux, since Termux runs inside an app and does not need to manage the kernel, bootloader or other early initialization components of the OS. This is why practically speaking, Termux is probably much safer to use and more stable during upgrades than those distros.

[agnostic-apollo]

Termux is probably much safer to use

Agreed, but I don't think I have ever seen Ubuntu break due to upgrades in a long time (likely an arch issue :p), things do break, but not something postinst messages would have indicated anyways.

[robertkirkman]

not something postinst messages would have indicated anyways.

At one point of upgrading Gentoo, usually a giant wall of text prints in the terminal that includes every message from the Gentoo News Items that is both detected as relevant to the current user's Gentoo configuration and installed packages, and detected as not having yet been displayed. Sometimes, the messages include directions for performing manual post-upgrade steps that are necessary for smooth operation of the OS afterward,

https://www.gentoo.org/support/news-items/

that is sort of the most extreme example of the kind of thing I am used to looking for, and other rolling-release distros like Arch Linux and Debian sid have similar kinds of things one needs to keep an eye out for,

but you are correct that in Ubuntu and stable Debian, usually all of the equivalent upgrades are handled in a fully automated way and it isn't really necessary to read the log messages to avoid getting a broken system.

[robertkirkman]

In termux-pacman, this currently happens on the command pkg upgrade anytime tsu is installed, without the user specifying "sudo" explicitly in any way:

:: Starting full system upgrade...
:: Replace tsu with main/sudo? [Y/n] 

I think this is a correct and desirable behavior we want, so this is fine, though unfortunately, I believe the same behavior is not really possible to achieve in termux-apt, and that is because this is just something that pacman does, and apt is just different and doesn't do that the same way.

termux-pacman does this when it is exposed to the variable TERMUX_PKG_REPLACES, so this is a subtle difference in the effects of TERMUX_PKG_REPLACES between termux-pacman and termux-apt, that I had to learn about the hard way a while ago when I accidentally messed it up and had to make a fix:

• fix(main/protobuf-static): for termux-pacman, remove TERMUX_PKG_REPLACES="libprotobuf" to prevent unintended prompt during every upgrade #24599

[robertkirkman]

This is good to merge now I think? I took a look at the reddit post, nobody there disagreed with this.

[twaik]

Sorry if I interrupt you guys, but probably we should implement some kind of compatibility script for su-over-sudo (as mentioned above) which will give some super-basic (at least) su functionality to keep script of users functional. Most of users do not interact with our discord, matrix, reddit or github spaces and most likely we will be flooded by "was tsu reoved???" posts of people who missed these posts [about tsu being deprecated and removed].

[robertkirkman]

Sure, however, unfortunately I am not sure what the best way to implement that is because: the closest equivalent commands in agnostic-apollo sudo are:

• sudo su
• sudo bash
• sudo login
• sudo -s -i

however, I have noticed that each one of these is subtly different from each other, and some things do not work in some of them, but do work in another variant, and I don't know which one is the best default.

I got into the habit of trying one and then if something doesn't work, using exit and then trying another one instead.

[robertkirkman]

Anyway, it was announced that in 2 weeks, tsu would be removed, so if that is delayed, it would mean the plans are being changed from the perspective of people who have already seen the announcement, and maybe the announcement should be edited to state that on the last day, someone has come forward with an objection (which is true).

but maybe that is overthinking the situation, and isn't very important to worry about.

[robertkirkman]

On the surface, sudo bash LOOKS the most like tsu:

however, internally they may be very different. I remembered that sudo bash did not work for something, but maybe in that case, it was that sudo overall couldn't work and su by itself was required. I am not sure. Also apparently from what I said at the time (owokitty in the screenshot), sudo bash worked for me but not for someone else.

[robertkirkman]

cancelling this because two people have requested tsu to remain:

• twaik
• Nervous-Stomach-8055