I wanted to share my notes on installing Eggplant Functional 22.5.0 on Ubuntu 22.04.2 LTS. It was successful and I’ve connected to our license server, created a new suite and starting working on new scripts under it. Additionally, I connected to a SUT and overall feel I’m ready to move forward. Without repeating steps already found in the online Eggplant documentation (I’ll link where relevant) here is the process I followed. I wrote it as experienced, mistakes and all, since it’s a good real-time expression of what you might experience yourself if you plan to run this same installation. Mileage may vary, of course…
Note: Eggplant officially supports Ubuntu 16, 20 64-bit for Eggplant Functional 22.5 so the experience here is based upon users who are running the latest LTS (Ubuntu 22.04.2) or a later version. The last LTS is going out of support, btw:
End of standard support for 18.04 LTS - 31 May 2023
0.Preparation: Read InstallNotes.txt that comes with the software archive download 
I didn’t realize that already having GNUstep installed would be an issue and reading that first might have tipped me off. As you’ll note below, I had a dpkg error installing Eggplant initially as it could not overwrite my /etc/GNUstep/GNUstep.conf so I had to take a second stab at it.
Also, the installation documentation has some pre-requisites to install for Ubuntu so I installed Metacity GNOME Desktop prior to moving on:
1.Initial Install: I went with dpkg out of habit to install my Eggplant22.5.0.deb file. Having not read InstallNotes.txt I didn’t force the install into /usr/GNUstep/ - even though that requirement doesn’t affect Ubuntu I would have reviewed the install a little closer to see just where it was installing. Executing this:
$ sudo dpkg -i Eggplant22.5.0.deb
produced:
dpkg: error processing archive Eggplant22.5.0.deb (--install): trying to overwrite '/etc/GNUstep/GNUstep.conf', which is also in package gnustep-common 2.9.1-2
I decided to use apt instead and executed:
$ sudo apt install ./Eggplant22.5.0.deb
Now, I got the same GNUstep.conf error as with dpkg because… yep, apt uses dpkg to install/remove packages. Since I already have GNUstep installed on another system, I decided to simply remove it from my Ubuntu instance and gave the installation another go:
$ sudo apt install ./Eggplant22.5.0.deb
Unfortunately, it turns out that even after removing GNUstep and the /etc/GNUstep/ directory, the install generated the same overwrite error. It looks as though the Eggplant installation creates the directory later attempts to overwrite the GNUstep.conf file. An additional error that appeared this time was:
"N: Download is performed unsandboxed as root as file…
…and noting the path of my downloaded file as:
couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
Executing the following solved the problem as this is a known bug that’s been around for some time in Ubuntu which generally assumes you’re installing everything via the remote package manager fetch:
$ sudo chown -Rv _apt:root /var/cache/apt/archives/partial/
$ sudo chmod -Rv 700 /var/cache/apt/archives/partial/
$ sudo chown -R _apt:root /var/lib/apt/lists
So why not simply right-click the file and select “Open with Software Install”? Well, I did exactly that next instead of re-running apt and it generated the same GNUstep.conf overwrite error. I remembered the failed install had likely created the directory since I had made sure it was deleted before executing my apt install, I went to delete it and discovered it wasn’t there…
Well, invisible directories aside, I decided to return to apt and then I remembered: Metacity; I forgot to log out and back in using Metacity desktop. I promptly did that and sure enough, the /etc/GNUstep/ directory was there. So, I promptly removed it and started again using Software Install:
And, the same error. So, it’s clear now that after removing this directory several times it is re-created by the installer and it sets itself up for failure down the road. Plan B:
$ dpkg --force-all -i Eggplant22.5.0.deb
Honestly, it was the last resort but after I did my forced install I was able to open Eggplant 
Only to encounter the following:
$ eggplant -LicenserHost <ip-addr>
/usr/GNUstep/System/Tools/gpbs: error while loading shared libraries: libidn.so.11: cannot open shared object file: No such file or directory
/usr/GNUstep/Local/Applications/Eggplant.app/Eggplant: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
So having installed tons of software on GNU/Linux systems I knew at least what this meant. The libraries needed weren’t in a standard location. I quickly identified where Ubuntu was keeping the main x86_64-linux-gnu libraries and found them at /lib/x86_64-linux-gnu/.
From the errors I already knew the Eggplant library locations:
/usr/GNUstep/System/Library/Libraries/
/usr/GNUstep/Local/Library/Libraries/
Next, I searched for at least one of the libraries not found (Note: one of them turned out to be provided by libssl1.0.0 which is obsolete and no longer updated, something we need to return to later):
$ sudo find . -name libidn.so.11
Which gave me:
./snap/core/14946/usr/lib/x86_64-linux-gnu/libidn.so.11
Oh, snap - of course… So, after doing some ln -s on the first six libraries Eggplant complained about, I realized symlinks was not the way to go. It was starting to pile up. And since this library directory was under snap I figured it needed to get into Ubuntu’s library path, so first I ran:
$ cat /etc/ld.so.conf.d/*
Which gave me:
/usr/lib/x86_64-linux-gnu/libfakeroot
# libc default configuration
/usr/local/lib
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
No surprise this was missing:
./snap/core/14946/usr/lib/x86_64-linux-gnu/
So, I did two things (possibly only one was needed, but to be sure…)
$ sudo ldconfig -n /snap/core/14946/usr/lib/x86_64-linux-gnu/ - ldconfig creates, updates, and removes the necessary links and cache.
And I added the snap libraries path to /etc/ld.so.conf.d/x86_64-linux-gnu.conf and then I went and ran Eggplant again…
Note on libssl1.0.0: I’ll reach out to Eggplant on this. Obsoleted libraries should not be linked to in practice, although it’s common enough to do for software that is older and no longer under development. Even then there should be some safeguard against potential exploitation. I suspect there needs to be a general update to the Linux installers as most of the list of libraries I encountered missing were older ones removed by recent Ubuntu releases. Disclaimer: I have no idea if this is an issue, just noting it.
2.Executing Eggplant: Now, there are two ways to execute Eggplant. You can click the shortcut from the Ubuntu menu (assuming you’ve properly set up your LicenseHost.lic or simply run it from the command-line with the host identified. I chose the latter:
$ eggplant -LicenserHost <ip-addr>
From here all was good.
I should note in closing (although there is much to note for future updates) that in another VM I have of Ubuntu, after installation of Ubuntu 23.04 pretty much every library has been upgraded so Eggplant was not possible to install. This is fine since the target should be the LTS version, but even with the LTS Ubuntu there are some hurdles to jump over. However, once those were jumped over, all was good.