On Fri, Sep 10, 2021 at 02:25:32PM +0100, Phil Morrell wrote: > On Fri, Sep 10, 2021 at 05:18:13PM +0530, Anuradha Weeraman wrote: > Then there appears to be this 93u+m project publishing essentially v2020 > as 1.0.0 beta, tagged as 'v1.0.0-beta.1'. It's release notes say "This > new fork is called ksh 93u+m as a permanent nod to its origin". It is > making more invasive fixes to the codebase and trimming unused > components, but there are some concerns noted over its backwards > compatibility with 40 years of scripts. > > https://github.com/ksh93/ksh
To give some context: The development of v2020 of ksh that took place on github.com/att/ast was rolled back last year, as it was primarily based on the less stable ksh93v- as a starting point which resulted in regressions and performance problems. The "att/ast" repository on which the development was taking was reset back to pre-2020 and the development has discontinued. ksh93u+/v- itself is not being maintained since the departure of Dr. Korn from AT&T circa 2014. ksh93u+m was a reboot attempt by Martijn Dekker et al. to build upon the last stable 93u+ release (not on v2020, apart from some cherry picked patches). This work has been taking place for over a year at this point, with the objective of making incremental changes, by fixing long standing issues, consolidating patches from RedHat, OpenSUSE, Solaris etc, removing unused code, fixing the build system, and testing across different UNIX variants. The distribution has come a long way, and the upstream maintainers have been carefully curating fixes and maintaining backwards compatibility. > 1) If there are possible edge-case compatibility issues, have you > considered a new source package and use of the alternatives system? This > would let Debian users choose between the two options for their use case > - maintaining existing systems, or writing new ksh scripts. This was the approach briefly, when we introduced ksh93 as separate package for those who didn't want to upgrade to ksh2020 and the issues that came with it. Since the revert of ksh2020 upstream, it was also reverted in src:ksh, making the need for a separate ksh93 unnecessary, and so has been removed from the archive. ksh93u+ is incremental, and backwards compatibility is considered seriously and further validated with a test suite. > 2) If you do go ahead with switching to the community distribution, then > "93u+m" is part of the name, not the version number, so I'd suggest: > > 1:1.0.0~beta.1-1 It does make sense to differentiate with the 93u+m prefix. Amending the proposed version below: 1:93u+m-1.0.0~beta.1-1 -- Anuradha
