3

If I fail to run make uninstall first, is the typical result no worse than simply having unused files lying around?

If the given is yes, is the answer universally applicable, or does it depend on the package? The automake docs state that an uninstall target is created, but perhaps there are exceptions.

Thanks

Paul Carey
  • 131
  • 3

2 Answers2

3

There is no way to guarantee that the make uninstall process for the new version will do the right thing with the version you have installed. You'd also need to make sure that you had identical configure options with your new and old version. The risk that it will do the wrong thing is just too great, especially if you're running this as root.

This is one of the many reasons why building proper packages for your system is so useful. Creating Debian or RPM packages is not hard, and there are tools like dh-make, which give you 90% of the work required, especially for autotools based packages. The advantages of using packaging are that when you upgrade, you know that none of the files from the previous version are installed and that you know what files the package has created on your system. You also get to keep the knowledge of how the previous package was built and can repeat the build with newer version. If you compile from source using "./configure; make; make install", there the chance that you'll lose knowledge of what options were used, what process you used, what patches you applied.

These advantages are definitely worth the small investment of learning to package your own software.

David Pashley
  • 23,151
  • 2
  • 41
  • 71
  • not even the original software's "make uninstall" command will surely remove all the files placed ... +1 for packaging istructions. – asdmin Aug 15 '09 at 22:04
0

Try to use something like checkinstall when forced to install from source. (it can also build rpm/deb packages)

Agree with David Pashley that building proper packages is the best way.

Not Now
  • 3,532
  • 17
  • 18