I am writing a software product and hope that it will work on a variety of Linux distributions. At the moment, I am trying to create some kind of Linux version of patches/upgrades of installed software. Gathering information on available updates isn't hard, nor is installation of updates, but I can find no coherent scheme for rolling an update back without uninstalling the application altogether.
I cannot find a way to do it for Redhat, Debian or any other family of Linux - at least I cannot find a way which isn't peculiar to just a few versions, and isn't obsolete or slated for retirement.
The method cannot be manual, I need to do it from a program, and it cannot depend on an esoteric utility which many of my customers won't have.
Does anyone have any ideas of how to do this for Redhat, or Debian, or SuSe, or any major distribution?
You don't need a previous version installed to install a newer one.
So, they're still not 'updates'. They're not small changes to a large thing, they're drop-in replacements for the whole.
That's what makes 'rollback' difficult. You need to enumerate the differences between them yourself, decide which are important, which aren't, which are defaults that probably shouldn't be reinstalled overtop of the existing ones, etc, etc. It might be possible to simply uninstall it and reinstall the old. It might not. There might be dependencies and dependency changes involved in that, too.
I also have to consider the possibility that the customer is trying it on basic, necessary software, so I would rather not uninstall and re-install in case something went wrong. They wouldn't like it if I wrecked the customer's system. I was hoping that someone had already worked out a system to do it, at least for some Linux family. I hate to concede defeat, but, at the same, time, I am probably not in a position to concoct a mammoth scheme for saving all necessary info on every update within my software. No one has ever solved this problem in a coherent way?
You are looking at rebuilding the world. Inside a package are a series of files and scripts.
Your package can work in several ways. You can inventory all the files owned by your application, save them to a directory based on the version, and then lay down the new files, however this may upset some customers when you use disk space they otherwise would not want, so you can make this step optional, but realize the stupider customers will screw it up.
Otherwise, you can use a simpler method than rpm or deb files, like a .tgz file that unpacks the changes, but also realize, there is more work, and getting versions is trickier this way.
Many customers have systems by which to load/remove software. You want a fits all solution and they don't exist. It will involve you documenting lots of things, and scripting many others yourself.
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.
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.
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.
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.
An aside - we have all experienced dll Hell at one time. This was/is caused by the fact that PC software developers do not have compunctions about overwriting existing dll's with a version of the dll 'they have to have' during installation. That seems to be what you are advocating.
One of the apps I am sysadmin and chief whipping boy for brings $US280 million revenue per year. Bills utility customers. Your uninstall implementation screws that up and my company will go after you mercilessly. Got a spare $30 million? This is what you are dealing in UNIX, and even Linux. We do not patch Windows servers for the reason I just mentioned. We go thru a horribly painful redeployment periodically.
One is on now.
We have four experienced Windows guys trying to upgrade from XP boxes to Windows 7, about 600 boxes. There are about 80 of those boxes they simply are going insane over. Mgt was getting cranky about it until we got an important person out on the floor to witness what was going on. Now they are thinking Linux desktops.... Meanwhile we are using Windows 2003 servers to let users runs apps they cannot run on their desktops.
Yet another thing I should add is that I've occasionally fought with installers that are over-paranoid about dependencies. Things that weren't prepared for the future, unable to recognize newer, backwards-compatible versions of its dependencies, and thus unable to install itself on systems it was perfectly capable of running on. Just another reason that trying too hard to outsmart your customers is shooting yourself in the foot...
The customers buy my software specifically for the purpose of managing their PCs, including installed applications, and installed applications are updated only on their specific orders. This is the exact function for which they buy my product.
There are already plenty of packages to manage systems. Aside from intense scripting, there are no other options.
Frankly, I have never been impressed with any software that tries to do what yours is trying to accomplish. Any other kitschy attempts will likely break a system. You may try image based rollbacks, but realize that could be disk intensive, take up lots of space, and leave the system broken in some cases. btrfs is a way to try to fix this by taking snapshots before a patch, with the ability to roll back, however that relies on the file systems being btrfs, which is still a work in progress, and requires a boot loader that can show you the snapshots. That part doesn't exist just yet.
Aside from having generic kickstart/autoyast etc images to rebuild a machine quickly and then apply their packages again (Spacewalk, RHN Satellite, SUSE Manager) you have little use for the tool you are building. Besides, with the three items listed, they do exactly what you want to do already, and Spacewalk is free (however the built in Oracle Express is severely limited, and last I looked the Postgres version was lacking in features).