Hi,
As Chase mentioned there were some issues using submodules (which is
what we started with), particularly around people not familiar with git.
Main issues were:
1. complaints about build failures due to the missing submodule, with no
clue on how to resolve
2. source code (git archive) releases, which of course do not include
the submodules, or even the .gitmodules files that would allow someone
to actually run a git submodule command after unpacking the tarball.
Of course if a git repo is available, I always prefer to use that, but
it seems I'm mainly in the minority.
But many of the people using CDE just download the source tarball and go
from there.
It would be possible I think to have a check in autogen.sh or configure
to look for and checkout any missing submodules but that's assuming git
is installed to begin with on the users machine.
Personally, I am not opposed to using submodules as long as we can patch
it when needed and we can resolve the #1 and #2 problems above.
Git subtrees seemed to "fix" all of those problems, though they are a
bit different to work with.
-jon
On 6/30/26 18:44, johngrimmreaper via cdesktopenv-devel wrote:
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
--
Jon Trulson
"The less you know, the more you believe."
-- Bono
_______________________________________________
cdesktopenv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
