RedHat has some sort of rollback to RPM. I read about it in Linux Journal. You have to execute extra command parameters at app. install-time. There is a database that is kept of the changes and locations of files.
-----Original Message----- From: Behalf Of Leo Mauler
The link appears to be broken.
Since we can't get to the link, does "make package from source" mean that you are recompiling the source code for the application? If so, then I'd much rather have my idea about an installer "wrapper" implemented as I really don't feel like recompiling OpenOffice.org from source just to get an uninstaller script/application. I'd much rather have an application that recorded the changes to the system and then either told you what they were or provided a convenient uninstaller script, or both.
--- "Sexton, Kyle" ksexton@gsihosting.com wrote:
For those who were interested in Check Install that I mentioned in the meeting, the URL is http://asic-linux.com.mx/~izto/checkinstall/. From the website which describes it better than I can:
"CheckInstall will create a Slackware, RPM or Debian compatible package and install it with Slackware's installpkg, "rpm -i" or Debian's "dpkg -i" as appropriate, so you can view it's contents with pkgtool ("rpm -ql" for RPM users or "dpkg -l" for Debian) or remove it with removepkg ("rpm -e"|"dpkg -r")."
It does this from your source packages.
On Tue, 8 Nov 2005 15:18:40 -0600 "Kelsay, Brian - Kansas City, MO" brian.kelsay@kcc.usda.gov wrote:
RedHat has some sort of rollback to RPM. I read about it in Linux Journal. You have to execute extra command parameters at app. install-time. There is a database that is kept of the changes and locations of files.
You're talking about the --repackage option. This essentially builds an RPM out of the files you have on disk ( including configs, etc ) that are supposed to be in that RPM and puts them in /var/spool/repackages/.
If you use up2date, yum, etc I believe you can set it up to always save a rollback on all installs/updates, however I found that it double ( if not tripled ) the time it took to do updates.
--------------------------------- Frank Wiles frank@wiles.org http://www.wiles.org ---------------------------------
On 11/8/05, Frank Wiles frank@wiles.org wrote:
You're talking about the --repackage option. This essentially
. . .
save a rollback on all installs/updates, however I found that it double ( if not tripled ) the time it took to do updates.
That's to be expected. First the installer has to open up the package to see what's in it, so that it can generate the list of things to back up, then go back and actually do the install. 3x sounds about right. I've given this some thought because I've done some work on protocols for packaging updates to my company's software. I wrote a quick-n-dirty utility that peeks into one or more tarballs (the main format our updates are packaged in), backs up the files about to be replaced, and then unpacks the tarballs. As an added bonus it logs the version numbers on all the binaries involved both before and after update, so you can confirm that you've got everything done. They used to have to do this by hand. The software installation team (who have to install the point release off CD, and then put in the updates that have come out since the release) loves it. Imagine how they'd like a real package manager like RPM or apt!
-
Frank Wiles -
Kelsay, Brian - Kansas City, MO -
Monty J. Harder