Actually no problem, I only just realised the virtual desktop in NX does persist after you disconnect, which is what I wanted. I will try this for a while and see how the reliability is.

thanks,
Biff.

Yeah, you can connect and disconnect to a session via NX, as you like. And it is incredible useful this feature.

I used in the past this feature as a "quick&dirty" hack to launch some GUI applications in a remote computer, then leave them to work. Kind of "screen" for X!

I talk about a kind of server soft for Internet Radio. Was with GUI even the Linux variant.

@bifferos

I looked in the RPM variant of NX6, for the structure. I do not think it can be packaged to Slackware, because we do not have a "pre-install" script, which they use heavily.

Practically, a Slackware package, like you know, has only a "post-install" script. The RPM or DEB use also another types of scripts.

I.e. "pre-install", "post-install", "pre-uninstall", "post-uninstall", "pre-upgrade", "post-upgrade"

Basically, what they do in the RPM?

They ship in "etc/NX/server/packages" those tarballs, like in the generic version, then use "pre-install" and "post-install" to handle them, and looks like other script domains are similar.

The real problem is you to invent a way to execute a "pre-install" script within a Slackware package, then you can pack that NX release as you like, inspired by their RPM variant.

----------------------

OK, maybe it could be packaged, if you assume the installed files to be really out of the package scope.

Looks like the nxserver script from /usr/NX folder, could be used as I said initially, as be called by install/doinst.sh

So, practically, your package should have the following structure:

usr/NX/etc/localhost/*
usr/NX/etc/packages/*.tar.gz
usr/NX/nxserver

then in the install/doinst.sh just call the usr/NX/nxserver --install slackware which will execute the real installation.

BUT, all the files which will be installed by that command are out of the package scope, just like GLIBC files from /lib(64), then you cannot remove them in other way than manually. And that's in fact, all of the real installed files, as the installer clean its room.

The good news is that looks like an upgrade will still work, even I do not know what sense will make in this case to install it two times, as we do.

Isn't a SlackBuild basically a pre-install script? You do whatever tweaking to the files/folders before it is packaged up, then the doinst.sh handles any post-install instructions...

Well, the "pre-install" script, at least on RPM (or DEB), have the advantage that it is run in an alive system, then can do a series of checks or behavior changes, according with the real situation.

For example, to switch to "upgrade mode" if particular files are detected. OR to refuse installation, if specific conditions are not meet.

------------------
Practical example: stopping the Apache service before installing an Apache extension or upgrading Apache.

Another practical example: the upgrading of a up and running MySQL server can have dramatic effects on the associated databases (read: all data is gone, Jim! WTF?)

IF the "pre-install" script stops the MySQL service before doing the upgrade, the safety of data is ensured in the databases.

------------------
I know, you will say: but, but a true admin should stop the services first.

True, but WHAT IF the admin forget that, or being habituated with other distros, he suppose that the process is automated?

Could be also multiple admins on that particular server, and the one who execute the upgrade use(d) Slackware only occasionally.

Combine that with automated tools like slackpkg or slapt-get, and you obtain a walking-bomb, waiting to explode.

------------------
BUT, what I really miss, is a "post-uninstall" or "post-remove" script, to do cleanups after removal.

For example, in the discussed NX case, practically all installed files could be removed this way, via an "post-uninstall" script.

------------------
At the end of day, you can look in the RPM variant of NX, to see what scripts use. 130K has its pre-install, for example ...