Linux

Actually, I cannot. My software will wake up on numerous varied systems of unknown configuration.

You are very knowledgeable (as always) and are confirming my fear that no one has solved this problem for any major Linux family. I suspect that the reason that this is possible in the Windows world is that uninstall scripts are somehow created.

Given enough time, I, or any competent programmer, could create a system, but if no one has created a facility for it, I will not have that kind of time to spend to implement just this one feature.

I had hoped that at least one or two of the major distribution families had some facility for doing this, but if an installation runs various scripts, I guess it cannot be automatic unless that also run an unistall script.

This leaves me wondering what to tell customers who complain that updating ruined their system.

It is not untenable. All you have to do is make the script take input and save the selections somewhere.

If the chosen destination is /opt/yoursoftware/version

you can easily create an /opt/yoursoftware/latest that is a link to the version installed.

Windows does not have the major advantage here. Sure you can play games with the registry, but *nix has been more flexible for decades. Nobody is suggesting you build an alternative to deb or rpm files, but you don't have to use them at all, and it makes it even simpler for dealing with any ELF compatible UNIX.

you have a tgz file, and then it explodes into a directory. That then has an install.sh and perhaps an uninstall.sh and perhaps an upgrade.sh script inside.
They do the right thing, and create backups, and the version management and voila.

If you run uninstall.sh, it then asks if you want to save your current version. If so, you can easily archive it off, because /opt/yoursoftware/latest points to the one they just installed.

This is the way *nix works.

Linux, and UNIX in general, are very "unmagical". Get the bootloader running, put the right files in the right places with the right permissions, and it should do what it's told. I've replicated entire linux systems with nothing but fdisk, mkfs, tar, and grub-install -- that is, replicated a system at the file-level, not the disk-level, and had it operate perfectly.

The UNIX philosophy is also "a program should do one thing and do it well". Your installer is your installer; your backup system is your backup system. Why would there be a special restore for applications alone when you can cover the whole system the same way? When everything is a file, you can roll back an installation by simply rolling back files. This makes recovering from installs simply a manner of keeping proper backups.

Windows on the other hand really needs it due to design decisions. Backing up files is not enough. Its opaque, always-live, and heavily centralized registry system means you can get all the right files in the right places but unless you capture the registry values at the exact right instant, it may be all for naught, and need an installer that doesn't just install and uninstall, but also keeps its own backups, does scanning and repair, and other such maintenance. Each application needs its own installer to do this, though a lot use one made from a template. And it still breaks down far too often because of how Windows has divorced its configuration from its filesystem.

Studying these great responses. I don't have the freedom to mandate tgz. My job is to inform users of all available updates for installed packages. I have to take them as I find them.

How do you not have the ability to tell customers how your software is installed?

I do have the ability to tell them how my software is installed.

I don't have the ability to tell them how updates for every other package on their system created by some random source should be updated, which is what I am discussing. Some packages may not be offered in tgz format, and when my software installs available updates for their other software by calling yum, apt-get, zypper, etc., those utilities will default to packages of type .rpm, .deb, etc.

Coming from a UNIX engineering perspective:

If your software ever tried to update other packages in this way, I would uninstall it, create an incident, and bring my legal team together to get you sued out of existence.

You handle YOUR software. You manage your own paths, and bring your own stuff to the party. If you update components on another person's system, you risk breaking it, and costing them a tremendous amount of money and pain.

That will translate into YOUR pain. Don't do it.

Manage your software, not theirs.


What you should do, is follow current best practices:

Create an installer that VERIFIES the minimum versions of software as provided by the OS. You can do that with apt, rpm, yum, whatever. When your vetting is done, you then issue message to the console, or via a log, etc that the system has been verified and may continue, and the installer continues, or that they are missing the per-requisites, and list them. By NO means should you go and get them. That is asking for trouble. You are a vendor, not a systems administrator.