SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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!
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:
# make install DESTDIR=/tmp/badprogram
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
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.
Last edited by ruario; 01-19-2013 at 01:44 PM.
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.
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.
@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.