Compared to other NX based projects X2Go has changed the strategy for building NoMachine library packages for Debian based systems. We recommend to other distributions to do the same.
We have discovered that the functionality of the libxcomp* packages is mid-heavily broken if they (probably esp. the libxcompext package) are not built against NoMachine's X server nx-X11 but built against the distro's own X-Server code. The newer the distro's X-Server seems to be the greater the problems seem to become.
Thus, we have set up the nx-libs.git project on the X2Go Git site: http://code.x2go.org/gitweb?p=nx-libs.git;a=summary
History: we (X2Go upstream) had tremendous problems with crashing x2goagent sessions (X2Go's pendant to nxagent) and we could narrow it down to the way we built the NX lib packages. So far, we used to build each NoMachine source tarball as a separate .deb source package.
The source tree of nx-libs.git shows the structure of the new package strategy. All NX tarballs are placed into one big source tree and then build–depending on each other during the build process.
With the new build method X2Go has incremented the .deb package version, so those packages bear a new package version number:
old: 3.5.0-X-Y~x2go1... new: 2:3.5.0-0~x2go1...
Also: as we pull several NoMachine upstream source projects into one big source package, we are not able to fully map the version numbers as used by NoMachine, e.g.
nxcomp 3.5.0-2 nxcompext 3.5.0-1 ...
will all be pulled into Debian source package
What packages with what exact version numbers are included in that big source package is documented elsewise (a README.NoMachine-versions and in debian/changelog).
As a side product, the nx-libs project also builds nxauth and nxagent. It is a non-X2Go-customized Git project and can be used by other NX based projects.