Hi

As a result of a revert of v2020 of ksh last year, the current version
on sid for ksh is as follows:

2020.0.0+really93u+20120801-10

With the next upgrade, we're looking to move to the 93u+m community
maintained distribution that has a different versioning scheme (starting
with 1.0.0-beta.1). Without bumping up the epoch, we can possibly version
it as follows, by using a newer date prefix:

20210510-93u+m-1.0.0~beta.1-1

However, I would like to request feedback to move to the following
version with a bump of the epoch:

1:93u+m-1.0.0~beta.1-1

Thanks,

Anuradha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Sep 10, 2021 at 05:18:13PM +0530, Anuradha Weeraman wrote:

As a result of a revert of v2020 of ksh last year, the current version
on sid for ksh is as follows:

2020.0.0+really93u+20120801-10

With the next upgrade, we're looking to move to the 93u+m community maintained distribution that has a different versioning scheme (starting
with 1.0.0-beta.1).

I was curious about why, and while I'm neither a ksh dev or user, in the context of Debian packaging it doesn't seem so simple. I'm trying not to
step on your toes, or dredge up interpersonal conflict.

https://github.com/att/ast/issues/1466

The impression I got is that there are at least 3 projects making claim
to "ksh93" going forwards. 93u+2012 is the last known stable, compatible version that has been reverted to and, crucially, has been shipped in
all Debian stable releases. There seems to be community demand and
distro maintainers support for collaborating on keeping the build system working on modern systems, which will not be merged back into the att
repo - do you know if this has happened, where the fork can be found?

https://tracker.debian.org/pkg/ksh

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

However, I would like to request feedback to move to the following
version with a bump of the epoch:

1:93u+m-1.0.0~beta.1-1

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.

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

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYTtcyQAKCRDbymUJHySO bF9GAQCsDoyo+nPYUetF2xeTnu+7lW++oUxWrteNF2cSeo64uAEAilpEeLvJi6Lj ZSQy/upc8KtLnPqXvXD1Ono137D1SQE=
=28FT
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Sep 10, 2021 at 07:37:55PM +0530, Anuradha Weeraman wrote:

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

Correction: rushed the last email, I meant to say that I agree that 93u+m
is not part of the version per se. I just thought that it would be good
to include, just for specificity. However, amending the proposed version
as suggested since it makes sense:

1:1.0.0~beta.1-1

thanks

Anuradha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Sep 10, 2021 at 07:37:55PM +0530, Anuradha Weeraman wrote:

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.

Ah I see, thanks for correcting my mistake about which project is which.
That way round I completely agree there's no need to use alternatives
and personally see no issue with bumping the epoch accordingly.

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYTvoOgAKCRDbymUJHySO bJSjAQCqXj+pkUPZtVhP6HqcMDgPp1n+B+WPWK32y6mT81nAYQD8DAXhS3R1MXsB Aa61NNPZorXu9ChDOEQAk/neiX4N/A0=
=sQwJ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Sep 10, 2021 at 10:04:08PM +0530, Anuradha Weeraman wrote:

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:

[...]

Correction: rushed the last email, I meant to say that I agree that 93u+m
is not part of the version per se. I just thought that it would be good
to include, just for specificity. However, amending the proposed version
as suggested since it makes sense:

1:1.0.0~beta.1-1

Hmm. If the project refers to itself as 93u+m does it make sense to
package it as ksh instead of something like ksh93u+m? This reminds me
of when debian first packaged openssh as "ssh" because that's what the predecessor package and the binary were called but in the long run
renamed it to "openssh". (And with a new name the version/epoch question
is moot.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Sep 11, 2021 at 10:16:00AM -0400, Michael Stone wrote:

Hmm. If the project refers to itself as 93u+m does it make sense to package it as ksh instead of something like ksh93u+m? This reminds me of when debian first packaged openssh as "ssh" because that's what the predecessor package and the binary were called but in the long run renamed it to "openssh". (And with a new name the version/epoch question is moot.)

That's certainly an option and I agree it would simplify things from a versioning standpoint.

However, I feel that given ksh93u+ is unmaintained upstream, existing
users of src:ksh stands to gain from the defect fixes and improvements
made without having to switch to a new package given that ksh93u+m
is maintaining the same code base that would have been otherwise
unmaintained. This would avoid having to maintain two packages, one which
is unmaintained upstream and one that is.

Open to your suggestions on the way forward.

Anuradha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Anuradha Weeraman <anuradha@debian.org> [2021-09-11 21:37]:

However, I feel that given ksh93u+ is unmaintained upstream, existing
users of src:ksh stands to gain from the defect fixes and improvements
made without having to switch to a new package given that ksh93u+m
is maintaining the same code base that would have been otherwise >unmaintained. This would avoid having to maintain two packages, one which
is unmaintained upstream and one that is.

Open to your suggestions on the way forward.

https://wiki.debian.org/RenamingPackages has a few good suggestions.
Maybe the transition package method would be appropriate here?
You could probably put the transitional package into the new source
package and use "dh_gencontrol --package=ksh -v20210511" in d/rules
to make it supersede the old binary package and ensure a clean
upgrade path.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmE87HgACgkQ+C8H+466 LVm8owv+PQsFFxkto6avQH1tk70oSIrLvQzuwltR+JcOHdPYTdYyxOlc4L/oxRBf lTOI3vWKIcjvu5vP6g9jsuFgD5B788XzkZvLarv37DXkeq9GIByNV0yeGOV7qQqk 1ElgI4IsDb3j/DkSrFLgQKlrz1pGGZfKiHca5X4v+Apfwixdsa9YYlScryeDr7FA vQDbG5FgLp6CjNHhTJrtKzUG29kuUoSs0uVXxVPIrWE1xX8NNhLDjlYAfvkNBG54 2U2UmNlnd3enAQ3h5akHCfx+wTfqPlecMkNwrT1QXnhLPCupF9QYgsscimGH94ep GV1IZG96AONaCL56y/ptr2LhyejC1UhDjq6RNhn3yy8

On Sat, Sep 11, 2021 at 07:50:52PM +0200, Timo Röhling wrote:

* Anuradha Weeraman <anuradha@debian.org> [2021-09-11 21:37]: https://wiki.debian.org/RenamingPackages has a few good suggestions.
Maybe the transition package method would be appropriate here?
You could probably put the transitional package into the new source
package and use "dh_gencontrol --package=ksh -v20210511" in d/rules
to make it supersede the old binary package and ensure a clean
upgrade path.

Thank you for this pointer. The transition package method does seem like
a good way forward in this case and I will look into this approach. I
think this addresses the original question on the epoch bump.

Thank you all for your inputs.

Anuradha

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)