If you want to release your own Debian package, please do not use a name like the following: "copperspice-1.8.0-amd64.deb". This has already confused people on FreeBSD who thought the package was our official release. Just make some minor change to the package name so it is clear this is your work.
Sorry for the naming.
Please nuke the links to the dropbox files. I have nuked the dropbox files themselves. Didn't expect anyone to be pulling them down other than you.
I forked and briefly submitted a pull request because I wanted the package logic and code to be in the main repo. It's long past time to have official DEB, RPM, and AUR packages for both run-time and -dev. I have to do some more testing, but I believe the run-time debian is solid. The -dev is where the wheels come off the cart due to conflicting executable names for the /usr/bin directory. The libraries have all been properly renamed so they can follow the correct flow in both DEB and RPM creation.
Personally I don't know how FreeBSD got into this conversation. The package that inspired me is an actual AUR build from 1.8 source which has the -none cmake files to fix the alternate bin location issue. I can tell you in all honesty that this AUR package,
https://aur.archlinux.org/packages/copperspice
works perfectly on the current fully updated Manjaro. I just tested it building and running this
https://sourceforge.net/projects/xpns-it-cs/
which also uses PostgreSQL. As long as you aren't using XFCE desktop, works perfect.
Right now the only reason what you have cannot work is the fact
lconvert,
uic,
lupdate, etc, have not had their names changed to csLconvert, csUic, csLupdate, etc. I don't have my current code base checked in, but that is the only thing actually
wrong. If those had non-conflicting names I could be done tomorrow with clean package code you could add to your automated release jobs. Another 2-3 days for RPM. I do a lot of packaging and when things conform to Linux standards, it has become a mechanical process for me.
I strongly caution you against thinking CPACK or any other generic package wrapping tool is a viable path forward. I have been pressed into the creation of custom ISO, DEB, and RPM files more times than I care to remember. Without exception higher level "wrapping" tools always paint you into a corner then become abandonware. The native tools they are trying to wrap move too quick. Native tools even change names.
Then Ubuntu does something stupid like UpStart instead of Systemd for several years https://wiki.ubuntu.com/Upstart
Distros (some) decide to split libraries across /usr/lib and /usr/lib64. Only some of them do this so your postin script has to jump through hoops moving things around once it figures out where 64-bit and 32-bit libraries are supposed to be. Some go the other way /usr/lib32 /usr/lib. Adding insult to injury some have changed their mind on how to do this so the 2012 release is different from 2014 and different still from both 2016-2020 then they go back to the original for 2022.
Then you have things like the GNU ABI bombs to deal with.
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
People like to tout the backward compatibility of Linux, but it does not exist. Just try to create packages that need to span 6+ years of distros, launch things at system startup, create both users and groups. It's ugly.
At any rate I shall endeavor to persevere. I want packages of my stuff that install properly.