Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've got sqlite 3.3.6 installed through ''yum'', but I need 3.6+. There's no RPM to be found for it, so I decided to install from source. That was simple enough, but now I have both versions installed, which is problematic.

I'd like to get rid of the old version, but if I were to run ''yum erase sqlite'', that would obliterate several things that depend on SQLite. Is there some way to tell the package manager to use the version I installed instead, without going to the trouble of creating an RPM for it?

Also, could someone explain this baffling interaction from after I installed 3.7.0.1 from source (Edit: see gnaman's answer below):

> sqlite3 -version
3.3.6
> which sqlite3
/usr/local/bin/sqlite3
> /usr/local/bin/sqlite3 -version
3.7.0.1
share|improve this question

4 Answers 4

up vote 1 down vote accepted

I'd use RPM to remove just the sqlite 3.3.6 and no dependencies:

rpm -e –nodeps name-of-rpm-for-sqlite3.3.6

This should keep your dependencies, but remove your RPM package. Additionally, make sure that you have /usr/local/bin/ in your $PATH.

share|improve this answer
    
-nodeps, like -force, is the Road to Hell –  cagenut Aug 17 '10 at 21:03
2  
As is installing newer-versions of already-installed packages from source. In for a penny, in for a pound. –  David Mackintosh Aug 18 '10 at 1:25

Also, could someone explain this baffling interaction from after I installed 3.7.0.1 from source:

Me too experienced the same problem. But on quitting and starting with a new Putty session window, it works fine. It returns the latest version. In my case, it is v3.7.3.

# sqlite3 -version
3.7.3
share|improve this answer
    
Thanks, you're right: which tells you what the path to something will be when you open a new session, not what it is in the current session. –  Trevor Burnham Mar 3 '11 at 18:35

What are you needing sqlite 3.6 for? If you're just needing it as a command-line application, then installing it from source as you have done is fine, it will just install in /usr/local/bin as you discovered.

Your PATH variable will determine whether /usr/local/bin or /usr/bin is searched first (based on the order of paths in that variable). If this is only for your use, you could also install the later sqlite in a subdirectory of your HOME directory and add it to your path.

Your simplest solution here is just to call /usr/local/bin/sqlite3

If you're needing SQLite to be used more widely, be wary... The reason is resolving dependency issues / recompiles for other libraries or applications also using sqlite's libraries. If you don't resolve these, you've no idea whether those will work or not.

share|improve this answer

There's no RPM to be found for it, so I decided to install from source. That was simple enough...

It certainly seemed simple enough but then you go on to mention the problems you now have.

"...without going to the trouble of creating an RPM for it?"

The time to learn how to create RPMs is now. You will have no end to trouble unless you install software through the OS packaging system.

In this case it'd probably be as simple as getting the spec file, bumping the version number, and deciding if the patches still apply to the new version.

share|improve this answer
1  
Great, the first non-terrible (perfect) answer. It irks me beyond imagination when people use an OS like CentOS and revert to installing things from source. –  hobodave Mar 1 '11 at 19:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.