Hi Chase,
Thank you for explaining the history. I understand the concern better
now, especially if submodules caused confusion for people building CDE
in the past.
I still think it is worth reconsidering for ksh93 specifically. I
updated the branch so the submodule workflow is documented explicitly,
including the clone and update commands for fetching the KornShell
submodule.
My main concern is future maintenance. CDE depends on KornShell, and
upstream ksh has continued to fix real bugs after the version currently
imported into CDE. Some of those fixes matter for portability and
non-Intel architectures, which is important to me right now because I am
working on the ARM 32-bit side of CDE packaging.
At the moment, KornShell-related issues are blocking my work on newer
Ubuntu releases. I can still build CDE for ARM 32-bit on Ubuntu 24.04,
but I cannot yet get it building properly for Ubuntu 26.04 ARM 32-bit.
Ubuntu 24.04 still gives me time, but I would like to address this now
so that, in the future, I can upgrade the Raspberry Pi systems where I
have deployed CDE. I do not want to spend time debugging KornShell
issues that upstream has already solved.
I also wanted to respond to Marco's earlier question on the list about
whether there are still people in IBM using or interested in CDE. I am
not an IBM employee anymore, but I did work there years ago, and IBM was
actually the second job where I had contact with CDE. I used CDE before
the source was opened, on HP-UX, AIX, and Solaris systems. After CDE
became open source around the end of 2012, I started using it on RHEL,
Ubuntu, and Debian systems. I even built a CDE RPM package for RHEL 6
back then, which was the stable Linux environment I used at IBM during
that time.
So I can answer Marco's question by saying that yes, there are people in
IBM who still know and appreciate CDE. Of course, there is usually very
little room to customize or install unofficial software on customer
systems, but spare machines and internal development environments do
exist. With the right approval, people can still experiment.
I also currently have an AIX 7.2 virtual machine, so in the future I
would be interested in helping with proper AIX packaging too, whether
that means installp/BFF packaging, AIX Toolbox-style RPM packaging, or
whatever workflow makes the most sense for CDE on AIX. Once there is a
clean community AIX package, we would have something concrete to show.
At that point, it may be worth trying to contact people around the IBM
AIX development side to see whether they would consider a newer CDE
package in the future.
For me, this is not a random packaging experiment. I have a long-term
interest in CDE both as a user and as a maintainer. I am now deploying
CDE on industrial Raspberry Pi setups, and I would like to keep helping
the project move forward on Linux, ARM 32-bit cheap boards, and
eventually AIX as well.
From my own experience, KornShell is still very important in IBM
environments, especially around AIX, IBM Zlinux on mainframe, and server
administration work. Of course, CDE's bundled KornShell would not be
used for production batch jobs or system scripts, but keeping CDE's
KornShell base easier to update would still make the project more
credible and maintainable for people who care about CDE in the IBM
hardware ecosystem. It would also send a strong signal that the project
wants to keep its bundled KornShell version current and maintainable.
For now, though, my immediate goal is to unblock the Linux and ARM
packaging work. I do not think CDE should blindly follow upstream or
track a moving branch. The submodule should remain pinned to a specific
upstream release or commit, and every future ksh update should still go
through normal review.
The benefit is that updating ksh becomes easier and more auditable. A
subtree makes ksh look like CDE-owned code; a submodule makes it clear
that CDE is pinning a known upstream ksh release, with local CDE deltas
kept as reviewable patches.
So I understand why the previous attempt was changed to a subtree. I am
only asking whether we can revisit the idea with a conservative policy:
pinned upstream ksh releases, explicit CDE patches, normal review for
every bump, and clear documentation for builders. That would reduce the
effort and time required to upgrade KornShell inside CDE in the future.
Best regards,
Reaper
On 2026-06-30 15:58, Chase wrote:
When I originally updated ksh93 from our very out of date in house
version of the ksh93u+m version, I added it as a submodule. People
found this too confusing and it was decided it would be made into a
subtree despite me advocating against it, and I thus stepped out of
maintaining this program. Thus, I don't think this will be merged any
time soon.
Thank you for your time,
-Chase
On Monday, June 29th, 2026 at 8:28 PM, johngrimmreaper via
cdesktopenv-devel <[email protected]> wrote:
Greetings.
First, thank you again for the positive feedback and review on the
recent Ubuntu/Debian packaging merge. I really appreciate the time and
attention from the CDE developers, and I am happy that the packaging
work was useful to the project.
I have now opened another merge request:
https://sourceforge.net/p/cdesktopenv/code/merge-requests/86/
This MR replaces the vendored dtksh ksh93 source tree with the
official upstream ksh93/ksh repository as a Git submodule.
I want to make one important point very clear: this does not upgrade
or change the ksh93 version used by CDE.
The submodule is pinned to the same ksh93u+m v1.0.4 commit that CDE
had already imported:
d4503c15572dd6b6b2cdd57c61583fbda27571a4
So this is not a KornShell version bump. It is only a provenance and
maintainability change: instead of carrying a copied source tree
inside CDE, the same upstream version is referenced directly through
Git history.
But off course, this will allow us to quickly install and benefit from
upstream korn shell project updates on the future.
Before opening the MR, I audited CDE's embedded ksh93 tree against the
official upstream v1.0.4 tag. Out of 1152 compared files, 1149 were
identical.
The only substantive local CDE delta was in:
src/lib/libast/features/aso
That change has been preserved as a CDE-side patch:
programs/dtksh/ksh93-patches/0001-backport-upstream-asocasptr-fix.patch
The patch is a small backport of the upstream _aso_casptr() fix
associated with ksh93/ksh issue #697. The build system applies it
before building dtksh and reverses it during clean.
There were two other differences found during the audit, but I did not
preserve them as patches:
- src/cmd/ksh93/sh/xec.c had a local NULL comparison simplification.
- src/cmd/ksh93/tests/libcmd.sh had whitespace-only differences.
I left those out intentionally. The xec.c change did not correspond to
an upstream commit that I could identify, and it appeared to be only a
local simplification rather than a required CDE functional change. The
libcmd.sh difference was whitespace-only. I thought it would be better
to keep the submodule as close as possible to the official upstream
v1.0.4 tree and preserve only the real functional delta.
I also tested the MR locally:
- verified the submodule is pinned to official upstream ksh93/ksh
v1.0.4
- verified the CDE-side patch applies cleanly
- built a local Debian binary package with dpkg-buildpackage -b -us
-uc
- installed the generated cde-desktop_2.5.3-1_amd64.deb
- confirmed /usr/bin/dtksh runs successfully
- confirmed dtksh reports:
Version AJM 93u+m/1.0.4+d4503c15/MOD 2022-10-22
For anyone testing the branch:
https://sourceforge.net/u/johngrimmreaper/cdesktopenv/ci/experiment/ksh93-submodule-v1.0.4-audit/~/
the submodule can be initialized with:
git submodule update --init --recursive
The goal of this merge request is to make future KornShell maintenance
easier and auditable, while preserving the current CDE behavior and
the exact same ksh93 version.
Thank you again for your work on CDE.
Best regards,
Reaper
_______________________________________________
cdesktopenv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
