Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #101636 > unrolled thread

Epoch bump request for ksh

Back to article view | Back to linux.debian.devel

Contents

  Epoch bump request for ksh Anuradha Weeraman <anuradha@debian.org> - 2021-09-10 14:20 +0200
    Re: Epoch bump request for ksh Phil Morrell <debian@emorrp1.name> - 2021-09-10 15:30 +0200
      Re: Epoch bump request for ksh Anuradha Weeraman <anuradha@debian.org> - 2021-09-10 16:40 +0200
        Re: Epoch bump request for ksh Anuradha Weeraman <anuradha@debian.org> - 2021-09-10 19:00 +0200
          Re: Epoch bump request for ksh Michael Stone <mstone@debian.org> - 2021-09-11 16:20 +0200
            Re: Epoch bump request for ksh Anuradha Weeraman <anuradha@debian.org> - 2021-09-11 18:30 +0200
              Re: Epoch bump request for ksh Timo Röhling <roehling@debian.org> - 2021-09-11 20:00 +0200
                Re: Epoch bump request for ksh Anuradha Weeraman <anuradha@debian.org> - 2021-09-11 20:40 +0200
        Re: Epoch bump request for ksh Phil Morrell <debian@emorrp1.name> - 2021-09-11 01:30 +0200

#101636 — Epoch bump request for ksh

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

[toc] | [next] | [standalone]

#101637

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#101640

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

[toc] | [prev] | [next] | [standalone]

#101643

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

[toc] | [prev] | [next] | [standalone]

#101656

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.)

[toc] | [prev] | [next] | [standalone]

#101658

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

[toc] | [prev] | [next] | [standalone]

#101659

[Multipart message — attachments visible in raw view] — view raw

* 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 │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[toc] | [prev] | [next] | [standalone]

#101661

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

[toc] | [prev] | [next] | [standalone]

#101647

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web