fix(main/coreutils): explicitly depend on openssl

[TomJo2000]

This PR changes our coreutils package to be built as separate binaries.

The main motivation is this post on the subreddit.
^{https://www.reddit.com/r/termux/comments/1loqx08/mysterious_errors_encountered_while_upgrading/}

Since the symlinked multi-call coreutils binary we currently ship for the package needs to depend on all of the dependencies for all component utilities.
Whereas the split independent binaries only need to link against what they need.

What we need to do in any case is explicitly depend on openssl for libcrypto.so.3,
which is needed by the cksum, md5sum, sha{1,224,256,384,512}sum utilities.
It seems the option of using libcrypto for those was introduced in 8.22 (2013) as a performance enhancement.
^{https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/NEWS?h=v9.7#n2134}
Though I am unsure if the coreutils package has been implicitly depending on it since the start of the Termux project.

[robertkirkman]

Coreutils has been built as multi-call binary for the entire existence of Termux.

In my opinion, 2.3 MB -> 7.3 MB is a big enough size multiplication (more than 2 times bigger) that it might not be worth increasing the package size of a package on every single Termux installation so much, just to better support a very old version of the app.

While versioned dependencies are normally discouraged in Termux for lower-importance programs, there is a precedent for making an exception to add versioned dependencies to some critically-important core packages, in order to make sure that upgrades on older Termux Apps are possible.

termux-packages/packages/libcurl/build.sh

Line 10 in c8e204d

TERMUX_PKG_DEPENDS="libnghttp2, libnghttp3, libssh2, openssl (>= 1:3.2.1-1), zlib"

Maybe in this case, the tradeoff of having a versioned dependency is more favorable than the tradeoff of disabling the multi-call binary?

[truboxl]

Though I am unsure if the coreutils package has been implicitly depending on it since the start of the Termux project.

Remind me why you change the maintainer field in the first place?

[TomJo2000]

Coreutils has been built as multi-call binary for the entire existence of Termux.

In my opinion, 2.3 MB -> 7.3 MB is a big enough size multiplication (more than 2 times bigger) that it might not be worth increasing the package size of a package on every single Termux installation so much, just to better support a very old version of the app.

True, it's a 200+% size increase in relative terms.
In absolute terms it's 5MiB's, which I'm not sure is worth worrying about.

While versioned dependencies are normally discouraged in Termux for lower-importance programs, there is a precedent for making an exception to add versioned dependencies to some critically-important core packages, in order to make sure that upgrades on older Termux Apps are possible.

termux-packages/packages/libcurl/build.sh

Line 10 in c8e204d

TERMUX_PKG_DEPENDS="libnghttp2, libnghttp3, libssh2, openssl (>= 1:3.2.1-1), zlib"

I absolutely agree, Having a versioned dependency on openssl makes sense here.
Should that be openssl (>= 3.0.0), or openssl (>= 1:3.5.0-1) though?

Maybe in this case, the tradeoff of having a versioned dependency is more favorable than the tradeoff of disabling the multi-call binary?

I am anecdotally aware of at least one user specifically depending on the coreutils binary itself,
so maintaining the multi-call build mode may be beneficial to not break that niche usecase.

[TomJo2000]

Though I am unsure if the coreutils package has been implicitly depending on it since the start of the Termux project.

Remind me why you change the maintainer field in the first place?

I have been set as the maintainer for the coreutils package since the version 9.6 update.

• bump(main/coreutils): 9.6 #23691

There were no objections to this at the time, I am happy to change it back to @termux, or list you as the maintainer if you think I shouldn't be listed there.
The main motivation for setting a maintainer was to have a point of contact regarding coreutils related issues and updates.
You could call it vanity I suppose.

I don't believe I should be required to have an encyclopedic knowledge of all packaging decisions made about a package years before joining the project, to put myself down as a point of contact regarding that package.

[agnostic-apollo]

As I previously said, you can use CODEOWNERS for point of contact, multiple people can be set. Better way than changing maintainer field when multiple ternux devs maintain the package. Feel free to set it to yourself for packages you exclusively maintain.