Daniel Bermond?

Post Reply
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Daniel Bermond?

Post by seasoned_geek »

Does Daniel Bermond hang out here?

He created this AUR.

https://aur.archlinux.org/packages/copperspice

In it he somehow generates the following two cmake files.

CopperSpiceLibraryTargets-none.cmake
CopperSpiceBinaryTargets-none.cmake

I'm not good with cmake, but need to generate the same thing for the -dev debian package due to not being able to put the binaries in /usr/bin. I'm sure this is something simply, but it is not obvious to me. I would rather have something clean instead of a cheap hack using sed

Thanks,
barbara
Posts: 446
Joined: Sat Apr 04 2015 2:32 am
Contact:

Re: Daniel Bermond?

Post by barbara »

We have not looked at the exact changes but he did alter something in our source or build files. This is both good and bad. Making changes to conform to the FreeBSD suggested approach does make sense on some level. But his changes caused compatibility problems. Every time someone uses the FreeBSD package they have issues and they contact our team. Once they go back and build with our source files all the problems seem to disappear.

From what we have heard he wanted to solve some issue, however the approach he took may not have been not a good design. CMake is really tricky and there are so many ways to get it wrong. We made a change in December so a client can build CopperSpice with their version of CsSignal and CsString. This required us to add the ability to unbundle the source code in CsCore. It took us over a week to get the CMake files correct on all 16 platforms.

We are actively looking at creating packages using CMake and CPack. One of the bottle necks is doing the CS build and then testing the builds on downstream projects for all supported platforms. There is no one standard fits all and thankfully we have people on our team who use a variety of different platforms.

We know you are looking at creating some packages. 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.

Barbara






please avoid using the name "copperspice" without adding

Barbara
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: Daniel Bermond?

Post by seasoned_geek »

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. :o

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.
Post Reply