3

I'm relatively new to Linux but I've been messing around with a Ubuntu VM to get more acclimated with it. I set up SSH, Apache, PHP, MySQL, Ruby, Rails, Passenger, and Git to mess around with my web development projects. A few of those I built from source, PHP and Git off the top of my head.

I was wondering what the general best practice is for recompiling / reinstalling something from source is? For instance, if I wanted to update Git to a newer version or enable an extension for PHP. Is it ok to recompile it and then install it over the current installation? Or is that a no-no and I should be uninstalling first before reinstalling?

If the latter, how exactly do you go about uninstalling something that was installed from source?

I tried searching around a bit but this seems to be a hard question to search for and I couldn't find anything when building from source, only when using package managers.

Thanks for any help.

EDIT: Thanks for all the input so far. You all seemed to answer my question about uninstalling but the major question I was looking for an answer for was:

Whether or not I should uninstall something I built from source before I recompile and install it again. Or is it ok to install over current installations whenever I need to change a config flag or update to a newer version?

Improve this question

4 Answers 4

Reset to default
3

Compiling your software in a VM is a great way to "get acclimated" with an operating system. No doubt all the dire warnings about rolling your own are true, for a production machine, but you'll be better off in the long run if you make your mistakes now.

If there is any reason to uninstall a previous version, it should be noted in a README or INSTALL file. If not, it should be safe just to run 'make install', which will overwrite the old version. Make a snapshot of your VM right before "make install". When, not if, something breaks, try to fix it. If you can't fix it, revert to the snapshot and try again.

If later on, you want to completely undo what you have done, the Makefile has all the information you need to uninstall. You can write your own "uninstall" target, or do it manually with just "rm". Bear in mind other things may have become dependent on the software in the meanwhile, so the snapshot strategy makes sense for uninstalling too.

For all the goodness of package managers, they have some faults. Some packages have huge dependancies to add features you are not interested in. Sometimes they don't have the version of the software you want. Sometimes they don't have the software at all.

If you run into one of these problems on an important machine, and you are entirely dependent on package managers your mistakes will be costly. But now, you can just revert to the last-known-good and move on, a little wiser.

Improve this answer
4
  • 1
    Yep, that's exactly what I did. Every time I got a piece installed and working I just made a new snapshot. Took me a few days to get everything playing nicely but it wasn't too bad. My biggest issue with package managers has been version issues.
    – anomareh
    Commented Jan 31, 2010 at 19:41
  • @anomareh: i highly recommend learning to build your own packages -- you can use the package manager's builtin uninstall capabilities plus get the versions you want, and if there's an unnecessary dependency you can remove it in your own local package. i haven't installed to /usr/local in years -- i either compile a local package or install to my $HOME directory.
    – quack quixote
    Commented Jan 31, 2010 at 21:26
  • @~quack Thanks for advice, I'll look into it. If you have any links for beginners on the subject that'd be great.
    – anomareh
    Commented Jan 31, 2010 at 22:12
  • 1
    In Ubuntu you can install checkinstall and then in place of typing sudo make install you can run sudo checkinstall -D This will install your program from source, but also give apt-get the ability to remove it like a normal program and create a .deb file.
    – Justin S
    Commented Feb 1, 2010 at 4:12
3

This might not be the anser you're looking for, but the best-practice on ubuntu not to install things from source. I'd say you want to be looking at apt or it's derivatives (aptitude et al). Git, for example lives in a package called git-core.

If you do end up installing things from source, you can be reasonably sure they they'll end up in /usr/local, which will allow you to manually remove old bits and piece if/when you decide to upgrade.

Some Makefiles also have uninstall / deinstall targets, but I'm not sure what proportion this is true for.

Improve this answer
2
  • Thanks I'd be happy to stick with package managers but a lot of the time they don't seem to have versions I'm looking for. If I recall when I was getting everything set up a while ago the available Git version was several major versions behind and I couldn't find php 5.3 only 5.2.x. If I'm building something from source does it only ever put files in /usr/local?
    – anomareh
    Commented Jan 31, 2010 at 19:39
  • 1
    /usr/local is a convention. Installing from source will only use /usr/local except when it doesn't. The Makefiles are the only authoritative source.
    – Richard Hoskins
    Commented Jan 31, 2010 at 20:02
1

There is no generic way of uninstalling source-compiled things; that's one of the many reason not to install anything from source. make uninstall will work sometimes, through.

You can do some changes to a package without installing 'raw' sources: take a look at this and this Debian-Administration.org articles.

Improve this answer
0

It is your machine, steam ahead! If it breaks, you get to keep the pieces.

Just some extra advise to make it less painful:

  1. Install under /usr/local (that is usually the default installation path, so you should not have to do much) or under your account, and set PATH to search there before the system's directories only for your account. Any breakage caused is contained that way. Safest course.
  2. Learn how to build your own packages (details vary with the distribution's packaging, look for tutorials and recommendations/standards on how to set it up and how a well-written package looks like). Grab the source package for the program you want to install as a starting point, edit to taste replacing the source by whatever newer version you crave, check if any distribution patches are applicable/needed, see if upstream suggests others. Install the result, normal updating won't touch it as long as it stays "newer" than the distribution's version. If something explodes, you'll always can fall back on installing the distribution's version using normal tools.
  3. See how to set up your own repository with locally knit packages, that way you can update any of them and normal update will install them.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .