If you have been following the saga you have a pretty good idea of the new features added to Diamond. These have not been turned over to the parent project and are not rolled into the code base! The exist only in my branch of my fork of Diamond.
Next on my list of tasks was to build a Debian package for the editor. If you ever want some Debian based distro or Debian itself to consider letting something in, it needs to already have packaging. The 12 year old boys can’t wait to find something pre-made where they can just change the “Maintainer” line and add it to the distro. I’m the insert-package-name-here maintainer seems to have some kind of bragging rights these days. Here’s a piece of wisdom.
If you are doing the maintainer job right, it’s a thankless shit job, not bragging rights.
Everyone who has ever maintained a package properly
roland@roland-U18CS-VirtualBox:~/Projects/diamond/deb_build.etc$ cat control.in
Package: diamond
Priority: optional
Section: editors
Maintainer: Roland Hughes <roland@logikalsolutions.com>
Installed-Size: @DIAMOND_INSTALLED_SIZE@
Architecture: @DIAMOND_ARCHITECTURE@
Version: @PACKAGE_VERSION@
Depends: libc6 (>= 2.27), libstdc++6 (>= 8.4), zlib1g, hunspell, libopengl0, astyle
Description: This is the Diamond text editor.
Diamond has been developed using the CopperSpice cross
platform C++ libraries. It supports EDT keypad navigation,
backups, color themes, and much more. You can configure a backup directory
where you not only store a backup copy with each save
and can control the maximum number of backups, but
also the ability to list and view all backups for a given
file. The Diamond Editor is open source and released under GPL V2.
It has been my belief that most of them just want to change that Maintainer line in the control file and submit a build.
Most of you will have never seen the guts of a Debian control file. Generally you just download a .deb file and open it with a software installer other than dpkg and magic happens. With dpkg and the command line there is far less magic because it will not auto-install dependencies. It will install a broken package, then you have to know some magic command line syntax to force it to install missing dependencies. For those who have never had to learn that particular magic incantation it is as follows:
sudo apt-get -f installTypically what you try to do is build with the oldest Debian (in my case Ubuntu) version you wish to support. Libraries are supposed to be well-behaved. You are supposed to have a line like this in your control file:
Depends: libc6 (>= 2.27), libstdc++6 (>= 8.4), zlib1g, hunspell, libopengl0, astyleThe stuff in () is there to indicate a minimum version number. Well-behaved packages have proper library naming and all linkage is supposed to be to a base symbolic link.
ls -al /usr/lib/x86_64-linux-gnu/libstdc++.so.6
lrwxrwxrwx 1 root root 19 Mar 10 2020 /usr/lib/x86_64-linux-gnu/libstdc++.so.6 -> libstdc++.so.6.0.25You will notice the symbolic link completely hides the actual library name. You will also notice that the actual library file name doesn’t need to contain the version number, or at least doesn’t need to have the same version number as was in the control file at install time.
roland@roland-U18CS-VirtualBox:~/Projects/diamond/deb_build.etc$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===========================================-==========================-==========================-===========================================================================================
ii libc6:amd64 2.27-3ubuntu1.2 amd64 GNU C Library: Shared libraries
.25 doesn’t really map to 2.27 via any means I know of.
Originally I did my development on Ubuntu 20. While I did put some values in for libc6 and libstdc++6 I decided to wait until I got around to building on Ubuntu 18.04 LTS to see if I needed further minimums. There is no way to reliably build that Dependency line via any automated means. Many people have made many attempts. The bottom line is you need to work from this:
roland@roland-U18CS-VirtualBox:~/Projects/diamond_debian_release$ ldd diamond
linux-vdso.so.1 (0x00007fffb3329000)
libCsGui1.7.so => /home/roland/Projects/diamond_debian_release/./libCsGui1.7.so (0x00007fc1401c0000)
libCsCore1.7.so => /home/roland/Projects/diamond_debian_release/./libCsCore1.7.so (0x00007fc13f5a2000)
libhunspell-1.6.so.0 => /usr/lib/x86_64-linux-gnu/libhunspell-1.6.so.0 (0x00007fc13f333000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc13efaa000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc13ed92000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc13e9a1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc13e782000)
libOpenGL.so.0 => /usr/lib/x86_64-linux-gnu/libOpenGL.so.0 (0x00007fc13e554000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc13e337000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc13df99000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc143ab7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc13dd95000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007fc13dadf000)
You need to know some utilities to find out what provides what. If you use only well-behaved libraries you can achieve Debian Nirvana. A single .deb file that installs on every Debian based distribution at least as new/current as your build environment. This is not a myth. It’s also not a simple straight forward process. I once created a far from insignificant .deb that installed on both 32-bit and 64-bit Ubuntu versions from 12 – 18. Yes, it took a lot longer than 15 minutes because we had a Web browser and graphics stuff to bring along not to mention a user account and entire Kiosk type application. It had to make substantive changes to the distro configuration then back them out when uninstalled.
You should not be surprised to find that even commercial companies cheat.
From a maintenance standpoint this is an absolute nightmare. They now have to maintain four separate build systems and someone has to hand create a different dependency line for each build environment.
I no longer subscribe to UltraEdit. I’m certain I still have some valid licenses for very old versions, but I just don’t use it anymore. I haven’t cracked open one of their Debian files but I remember they had spell check and the on-line doc for Windows says they use ASpell. That’s where this packaging got screwed, the spell checker.
libhunspell-1.6.so.0 => /usr/lib/x86_64-linux-gnu/libhunspell-1.6.so.0 (0x00007fc13f333000)It’s 1.7 in Ubuntu 20. Hunspell did not follow proper/traditional naming conventions. LibreOffice uses it and there was a mad rush away from OpenOffice once Oracle bought Sun Microsystems. Aparrently the powers that be at hunspell have avoided adopting tradition for over a decade.
Oh! Just bundle it with your .deb. Weeeeellllll….
The Diamond Editor is open source and released under GPL V2.
Diamond license
Hunspell is a free spell checker and morphological analyzer library and command-line tool, licensed under LGPL/GPL/MPL tri-license.
Hunspell license
I went down this rabbit hole with Artistic Style.
You will notice all of those letters aren’t the same. GPL != V2 != V3. Theoretically I would have been okay with Artistic Style when I was adding the functionality but the GNU Emacs developers didn’t use the library version either. Instead they did what I did, built an astyle command line and passed it things then consumed the output. This got around a lot of licensing issues GNU didn’t wish to deal with at the time and obviously hasn’t cared to address since.
I asked about the licensing issue in the CopperSpice forums but was either unclear or, more likely, just like me, nobody wanted to go down that rabbit hole. Even most of the lawyers I encounter try to avoid rendering judgement on differences when it comes to OpenSource licensing.
The Debian from Ubuntu 18.04 64-bit installed just fine on Ubuntu 20.04. After all, hunspell was hunspell according to the control file. It simply wouldn’t run because it was looking for a file with 1.6 in the name and on Ubuntu 20.04 LTS the file has 1.7 in the name. I could do a hack on the command line and make it run.
sudo ln -s /usr/lib/x86_64-linux-gnu/libhunspell-1.7.so.0 /opt/diamond/libhunspell-1.6.so.0Yeah, that’s the kind of hack you want to see.
I could thump this output into a variable during postinst and add a bunch more code to generate the hack on each target system.
ldd diamond | grep -i hunspell
libhunspell-1.6.so.0 => /usr/lib/x86_64-linux-gnu/libhunspell-1.6.so.0 (0x00007fbf5ef12000)
That would suck even worse though because I would have to have all kinds of safeguards against libhunspell-0.5.so.0 or some other much lower number. I could make the control file protect me from not having a high enough version, but it can’t protect me from that being one of many.
As of right now, since I’m still working on this, I took the cheap and evil route of creating 2 files.
Keyboard macros do not work! They were too tightly coupled to MainWindow class so I just conditionally compiled them out for now. I’ve used keyboard macros four times during my thirty plus year career. Two of those times were at gunpoint from a client who was completely enamored with keyboard macros and “learn” keys. There is always a better way to do something than a keyboard macro. At some point I may fix them.
For those who haven’t been following the entire saga, this post mostly sums up the new features that are not yet part of the code base.
