FS#68098 - [ksh] v2020 is unmaintIaned and unsupported
Attached to Project:
Community Packages
Opened by Matthew T. Hoare (Head_on_a_Stick) - Sunday, 04 October 2020, 08:53 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:09 GMT
Opened by Matthew T. Hoare (Head_on_a_Stick) - Sunday, 04 October 2020, 08:53 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:09 GMT
|
Details
The 2020 version of ksh that was developed by Kurtis Rader
is now unmaintained and unsupported by AT&T.
See the note on the v2020.0.0 release page and also https://github.com/att/ast/issues/1466 Furthermore ksh2020 is significantly slower than ksh93u+ (the last stable release of David Korn's original implementation): https://github.com/att/ast/issues/1449 I would therefore humbly submit that it might be better to revert to ksh93u+ (or perhaps ksh93v-) for this package. |
This task depends upon
Closed by Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:09 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/ksh/issues/1
Saturday, 25 November 2023, 20:09 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/ksh/issues/1
ksh93u+ is said to have problems, CVEs, and is hard to build.
ksh 2020.0.0 is said to have problems and be slower.
It's unmaintained because the community fought about it and AT&T decided *no one* gets to keep their toys if no one can agree which toys are better. Now once again, it's unmaintained, but not just the 2020.0.0 edition -- there is *no* ksh maintained codebase, not even the "ksh-community" fork which has yet to demonstrate it isn't vaporware and has a grand total of 0 commits.
There doesn't seem to be a clear argument which direction to go in.
And the main argument against the ksh2020 speed is "it needs to use buildtype=minsize or -Os" followed by "using a proper system malloc is comparatively slower due to undocumented quirks of the AST Vmalloc". The former is something I could trivially fix in packaging. The malloc change appears to be very divisive...
I'm not sure what the right solution here is. But currently I am on holiday so I don't have the time to handle this anyway.
Debian reverted to 2020.0.0+really93u+20120801-8 (best described as "idk what versions are" but uses the 93u code)
Fedora reverted to 20120801.
Gentoo, Void, nixos use 2020.0.0
I'll have to give this some serious thought going forward...
https://github.com/ksh93/ksh
Johnothan has adopted the AUR git package [2]. This is what I have currently installed on my PC. It builds fast and without errors. I am happy with it, although I (still) use dash for /bin/sh and zsh as a login shell. Ksh [1], in a couple of simple tests I have done, is much faster than dash, let alone zsh. I may some day use ksh instead of dash.
Debian Stable (currently bullseye) still uses the ksh2020 version, however Debian Testing and Sid have switched [3]. Debian is using a transitional package for the switch, presumably because previously the version was date based (2020...) whereas now it is number based (1.0.3). So the transitional package in Debian Testing pulls [3] and the transitional package can then be deleted.
Ubuntu too has switched [4] however they are using a beta version, not (yet) 1.0.3.
Fedora too has switched [5].
In a nutshell, some of the most popular and deployed distros have switched to [1] so it would be nice if Arch could switch too!
[1] https://github.com/ksh93/ksh
[2] https://aur.archlinux.org/packages/ksh93-git
[3] https://packages.debian.org/search?keywords=ksh93u%2Bm&searchon=names&exact=1&suite=all§ion=all
[4] https://packages.ubuntu.com/jammy/ksh93u+m
[5] https://packages.fedoraproject.org/pkgs/ksh/ksh/
FS#77578As of now my current review is that Piscium is probably right and the https://github.com/ksh93/ksh project is the one to follow now.