[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Epoch bump request for ksh



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


Reply to: