Uninstall Stuff
 

I installed some software from source, specifically sip-4.14.2. It broke a some of my desktop plasmoids and made me very sad.

Now I need to remove it, but I'm not sure how since I didn't make it into a tgz first.

*Note to self: Learn to make Slackware packages before next install.

Anywho, as I was saying, I've never managed to break anything important on Slackware before now so how do I hunt down and rid myself of all the sip stuff?

I'm running Slackware 14.0 on a crappy netbook.**

** I'm also accepting donations for a spiffy new desktop. And beer. But mostly a spiffy new desktop.

If you are lucky - and still have the source package from which you made it - "make uninstall" should remove it. If not, you'll have to look closely in the makefile and try and figure out where it put everything. If you are *really* unlucky, it will have overwritten some of Slackware's files, which will need replacing too!

A good way to learn Slackware packaging is to take the slackbuild file from an existing slack source package, and tweak it to suit your new source tarball. That's what I do! ;)

I ain't lucky. I tried make uninstall first thing.

I rarely have to install extra software so I've never bothered learning the package tool beyond install and remove.

Is there a reason you wanted sip-4.14.2? Because sip-4.13.2 is already included in a Slackware full install.

Most makefiles accept a DESTDIR parameter to install the software to a specific directory. It might be possible to install the software to a temporary directory to have a complete list of the files installed, for example:

This should create the program directories and files (usr/bin, usr/share, etc) under /tmp/badprogram. Once this is done, it's just a matter of looking in the filesystem for the files installed in DESTDIR.

Another suggestion is to always install to /usr/local when installing from source, it's easier to remove stuff from there. Usually the --prefix parameter to configure changes the install location, for instance


HTH

Diantre makes a good point indeed. In order to know what files to remove, you need to make another installation into a different directory and then make manual comparison and remove the right files.

Well but what if you would make that installation into a default location, overwriting the files you already have? You could do make uninstall right afterwards and it would delete the files it just installed freeing your system from that sip.

Third option is to do nothing as those files laying around in your file system would not put any load on your system sos your Slack installation would not be any slower than if those files are removed. But if you really want to get rid of those files then yes make another manual installation from the source and follow up with make uninstall.

I did a quick test for you on the only Slackware install I have to hand right now, a fairly minimal (no X or anything like that) Slackware 13.37 installation. I took sip-4.14.2.tar.gz and compiled from source and installed with all defaults (python configure.py; make; make install). It placed down the following files:

Since you have Slackware 14 (with python-2.7.3) you might want to look for the same files but in /usr/lib/python2.7/site-packages/ (or lib64 for 64-Bit) and /usr/include/python2.7. Before you delete them however, check their timestamps and use this information along with a find command to locate other files that could have been created/installed around the same time (you might need to do some reading of 'man find'). Things might be different when installing on a more complete Slackware install, particularly when it is a different version of Slackware.

To save yourself a problem next time, also read 'man slacktrack'. This tools comes with a standard Slackware install and should help you track source installed software.

To everyone suggesting 'make uninstall' I would just like to point out that sip provides no uninstall target.

This is why you are always best either making a real package or at least doing your own tracking (so you can create a log of what was installed).

Ahh, good point!!

Having looked at slackware-14.0/slackware/MANIFEST.bz2 and slackware64-14.0/slackware64/MANIFEST.bz2 for what is included in the official l/sip-4.13.2 packages, along with what slackware-14.0/source/l/sip/sip.SlackBuild does, I think it is fairly unlikely that any extra files were installed.

Issuing the following two commands as root should get you back to the original state.

Kill all the sip files currently installed:
Reinstall the official sip package:
And in the future, if you ever want to install an updated version of a package that is already included in Slackware, just use the SlackBuild script and then upgradepkg. ;)

Thanks, it's more better now. I have not heard of slacktrack, but it sounds terribly useful. I will look into it unless something shiny distracts me.

Good to hear! Remember to mark the thread as solved. ;)

EDIT: D'oh! You already did.

This thread might be solved, but here's another thought. It's never too late to make a package. In cases like this, you could make the packages even after a "make install" has gone to the system. Install them and remove them -- voila, stuff removed from the system.

And maybe another afterthought - never build from source as root.

I never do ... I always use fakeroot when building things, so that the Slackbuild script and "/sbin/makepkg" get all the permissions and ownership right.

It does mean that Makefiles need to process "DESTDIR=" correctly. "gtk3" is a prime example where "DESTDIR=" does not work.

@MadMaverick9

What's a buzz about using a fakeroot in your particular case? Just to avoid possible privilege escalation?

Can't we chown a directory where a new package sits after it was built by a root to a non-root user?


Thanks in advance.

@cfdisk: But most SlackBuilds don't work like that, they don't ask you to become root just before the chown step, rather they expect you to run the entire thing as root.

When making, tweaking or debugging your own SlackBuild scripts if you don't fully trust DESTDIR is being accepted during the 'make install' step or equivalent, you could end up with files actually installed rather than ending up in your staging (packaging) directory. Running the SlackBuild under fakeroot ensures that permissions/ownership are correct in your packages but prevents the possibility of files accidentally being 'installed' into the system rather than ending up in the package.

Yes, there are several other ways around this but fakeroot is a handy convenience, so personally I always have it installed on my machines.