2

Is it possible to keep RPM content in the filesystem after the uninstallation ?

Basically, I don't want to erase the files generated by the RPM when someone runs rpm -e, but still remove the package from the list of installed RPMs. I want to uninstall my application manually from the server and I cannot find a way to do so.

Thanks in advance.

pwan
  • 2,894
  • 2
  • 24
  • 38
Daddou
  • 379
  • 1
  • 4
  • 13
  • What do you mean by 'keep' RPM content? You installed with `rpm -i package.rpm`, this in essence, 'extracts' contents of the package into the right places in your system. The `package.rpm` itself remains where it is. When you do `rpm -e package` (not `package.rpm`), it in essence, 'deletes' what was extracted earlier. The package file is untouched. – ArjunShankar May 03 '12 at 09:27
  • Yes, i wanted to know if it was possible to keep the extracted files in the filesysem after an rpm -e. I want to be able to delete them manually. – Daddou May 03 '12 at 09:41
  • 2
    Isn't it just better to *not* run `rpm -e`? When I run `rpm -e` I *want* the files to be deleted. You would be violating the 'principle of least surprise' if your rpms were special in some way. System administrators would be pretty annoyed by this, for example. – ArjunShankar May 03 '12 at 09:50
  • What could i do if i wanted to reinstall my RPM but keep the old content ? An update would delete the old files anyway. – Daddou May 03 '12 at 09:52
  • To be clear, the behavior you want is: When somebody runs `rpm -e` to erase your package on a system where your package is installed, you *don't* want the files to be erased, but you want the package to be removed from the system's list of installed packages. If so, I think you should specifically edit and mention this in your question. It is not clear there. Anyway, as I said, sounds like a bad idea to me (if it were even possible) – ArjunShankar May 03 '12 at 09:58
  • The content changes after install? If so, where is this content located after install? What is this content? – ArjunShankar May 03 '12 at 09:59
  • That's exactly what i want yes. I will rephrase my question to make it clearer. – Daddou May 03 '12 at 10:10
  • You might want to talk about *why* you want to do this. The last couple of comments you made about re-install sound like you're doing this to solve some *other* problem. Also: The content changes after install? If so, where is this content located after install? What is this content? – ArjunShankar May 03 '12 at 10:13
  • The content is simply a PHP application packaged in a custom RPM. I can't have two installations running in parallel so i'm obliged to uninstall my old RPM before deploying the new one. But i want to archive all my installations in case something goes wrong. I can't do this when the rpm -e deletes my old files and i cant' delete the rpm from the list of installed packages without it. – Daddou May 03 '12 at 10:25
  • @Daddou You can save the installed files somewhere before uninstalling. Alternatively, just keep the old RPM with which you can restore the old state. – glglgl May 05 '12 at 14:34
  • What you want is wrong on many levels. rpms should be designed **never** to touch files/directories that have been changed after installation. And the application should put dynamic data in correct directories (/var most probably). Certainly never in /usr. Config files go into /etc and are marked %config in spec files...The list goes on. – Stan May 09 '12 at 15:56

3 Answers3

3

Specfile creation

From this perspective as a package creator, you can flag files as configurations. John Warbrick at Cambridge Uni has a good rundown of the different file markings you can use in an RPM specfile and how they behave during upgrade.

Files marked %config, if changed, are:

  • left behind on uninstall but renamed with an .rpmsave extension
  • untouched on update or reinstall, but the payload copy is installed with an .rpmnew extension

Warbrick does not deal with straight package removal: if a file marked %config is unchanged, erasing the package will remove the file. (Bear in mind that, according to RPM scriptlet ordering, RPM update or reinstall begins with erasing the old package, before the new files are lain down. I.e., the old unchanged config is replaced with the new config.)

It would be an abuse of RPM file classification to mark something a %config that is not really a config. This is important because sysadmins need to be able to trust the package payload. Plus, you probably don't want such a file to be renamed with an extension.

Your best hope then is to create the file during RPM %post. Files copied to the filesystem in %install are checked against the %files list and stored in the RPM database, but files created in %post are not. Again, this an abuse of the RPM spec file format, but if you mention it in the %description and any other documentation, but especially if it's logically expected behavior in the context of your package, you'll maybe get some sympathy.

Existing packages

For sysadmins wanting to remove a package without removing its payload, you use rpm --justdb. First, check the file list:

# rpm -ql $PACKAGE | tee $PACKAGE.payload
[rpm returns list of files, tee saves it in the file $PACKAGE.payload]

# rpm -e --justdb $PACKAGE

(At this stage, you may get a complaint about deps, so repeat with --nodeps if you must.)

And finally, check that the package is gone, but payload is still there:

# rpm -q $PACKAGE
package $PACKAGE is not installed
# ls -l $(<$PACKAGE.payload)
[ls queries list of files saved in $PACKAGE.payload]

(Or for a more reliable ls if filenames contain spaces, which would be unconscionable in RPM.)

# cat $PACKAGE.payload|xargs -d '\n' ls -l

Other observations

Note that for a package created using the method outlined at the top of my answer, attempting to list the files it owns with rpm -ql $PACKAGE will not show those persistent files. Another consequence of throwing down files during %post is that another package which "owns" those files could overwrite them unexpectedly - they're not listed in the RPM database, so they're not protected.

The two methods I've outlined break Best Practices for both RPM package creation and sysadmin. Please be very careful how you use this dangerous "little bit of knowledge". Maybe there's something else you could do to create the desired situation.

(Finally, I know this is a question from four year back. It wasn't answered. It needed answering. Cheers.)

Rich
  • 380
  • 4
  • 11
0

rpm -e --repackage package_name will drop a re-installable copy in /var/spool/repackage. You can extract from that rpm using rpm2cpio if you need those files back individually.

Aaron D. Marasco
  • 6,506
  • 3
  • 26
  • 39
  • In theory, yes. But AFAIR this leaves a RPM with wrong checksums or something like that. (At least, there was once upon a time a corresponding issue...) – glglgl May 05 '12 at 14:35
  • That I have not heard, but yes, if the OP has modified the files, their checksums (and timestamps, etc) would be invalid when verifying the rpm when installed or when extracted. – Aaron D. Marasco May 05 '12 at 19:27
0

One of the advantages of RPMS is exactly that: you can uninstall (remove) all the files easily. If you want to install the files provided by an RPM manually, simply unpack the RPM as root, with:

cd / && rpm2cpio *.rpm | cpio -idmv

It's not a good idea, but you can unpack RPMS like that elsewhere (e.g. under ${HOME}), and that's very useful. You may need to adjust some environment variables though. You don't pollute the RPM database but still use the contents of an RPM. Of course your application may get broken by system updates, because it is not protected by dependencies. Anyway this is how you "install" and RPM if you are not root. Removal is also easy (if installation path chosen suitably).

marcindulak
  • 31
  • 1