Ask HN: Why do Makefiles typically not include an uninstall script?
I'm typically a package manager guy, once you start screwing with the status-quo especially on distributions like Ubuntu, things get strange really quickly.
Case in point, Redis, the Makefile is so simple, and the code/project so clean and with so few dependencies, there's not even a `./configure` stage, why doesn't it include a `make uninstall`.
`make install` must generate a file list to perform the uninstallation, it should be trivial to uninstall those files.
Am I missing a trick, is there some way to snatch the file list from `install` and feed it to `rm`, or do they not include an `uninstall` task incase that try to uninstall something that's running (but, even that is a small portion of things which are installed, and surely 9/10 times it would keep running until stopped/rebooted??)
Thanks HN!
9 comments
[ 3.2 ms ] story [ 27.1 ms ] threadhttp://asic-linux.com.mx/~izto/checkinstall/
Thats a half-decent idea, nice smart move, and it looks like the authors motivations weren't dissimilar to my starting point for this query.
I do wonder however if it isn't slightly over-killed, `make install` must generate a list of commands to run, or there should have been some way to stream the output of `make install` to a text file, that it might be undoable ?
I think there is no `uninstall` command included usually because most packages that are installed using `make install` are system libraries that other packages depend upon. And so just uninstalling that one package could result in a broken system. There may be some other historical reason, but that's my guess.
EDIT: Yes, `checkinstall` is a really cool idea, but I've had a hard time getting it to work reliably in practice. Building a deb is a complicated process, so it's not surprising that attempting to automatic that process is not 100% reliable. But you should try it out, maybe you'll have better luck that I did.
Xstow is also small enough to fit it into eg: ${HOME}/opt -- and it is able to "unstow".
[1] http://xstow.sourceforge.net/
edit: formatting
/usr/local/bin/<program> -> /usr/local/<program-version>/bin/<program>
Similarly for man, lib etc. If you don't put stuff under /usr or /usr/local (but, say under /opt or ${HOME}/opt) -- you need to update your paths (PATH, MANPATH, USER_LD..).
Uninstalling just means removing the symlinks (unstow) and deleting the tree under /wherever/<program-version>.
This is what I do in my bashrc (which I use across a range of systems, some of which are mine, some of which I only have a user accounts -- some on Solaris, most on a flavour of Linux):
The part about "pybin" is just becaus I do: And can then pip install stuff and have it available without having to worry about activating a virtualenv etc. I generally keep large packages in separate venvs -- but install stuff like mercurial in the "misc" one.Note that the structure of my opt-folder mirrors that of eg. /usr/local, so:
(I also have src and xstow in there -- src for source packages I want to keep around, xstow for xstow-installed packages.)And to repeat, if you put your xstow tree under /usr/local or somewhere most likely already in your path, it should "just work" without having to set any extra variables -- and is more useful for eg: installing a system wide service (like Redis for production use).
edit: forgot to add export of environment variables to the .bashrc snippet
edit: the "${HOME}/opt/${unps}" points to a directory that contains architecture specific binaries; the unps-variable, is set to be `uname -ps` (with some trickery) -- and is then used for finding local binaries and setting some options like PAGER.
The `brew` executable knows about the correct flags to give to `--configure` within it's own context, so it rarely goes wrong.
That's a good point, there is no dependency resolution at this low-level; and with that in mind, there's probably a good way to uninstall things by hand, if you really wanted to.. thanks for the thought.
http://sources.redhat.com/autobook/autobook/autobook_109.htm...
Note this refers to GNU Stow[1] which is implemented in perl -- I much prefer the xstow variant[2] as it is more self contained. YMMV.[1] http://www.gnu.org/software/stow/ [2] http://xstow.sourceforge.net/