What do I do with the rpm if I build from source?
 

I feel stupid because I don't know the answer to these questions...

Some software I have needed a more up-to-date version. I have built the programs from source. If I had a previous RPM installed, should I just install over the programs (assuming I am installing into the correct directory).

I can delete the rpm with the --nodeps tag, of course, but then my other question is, will new and different rpms be aware of the program I have installed?

For example, I have needed to build a version of mjpegtools for a piece of software I have... I can delete the old rpm, but then, will the old and new programs be aware that I have installed the source version? Or should I just install over the rpm, and therefore the rpm looks fine (albeit with the wrong version number)... and will new programs in rpm know I have mjpegtools, even though I didn't install an rpm of it...

Thanks in advance,
Kris

If you are building from source on an rpm-based system, you should build a binary rpm and install that. If the spec file is not part of the source file, then you can try to use the spec file from the existing source rpm package.

Using the default './configure; make; make install' in an rpm-based system will at best install a parallel version in a different location (usually the '/usr/local' or '/opt' hierarchy), and at worst overlay parts of the existing rpm. The problem with this is that the rpm database (which should be managing all installed software) is now out of sync with the reality on the filesystem. Future updates may pull in files which conflict - but with no way for rpm to know this. This can lead to system instability.

If new rpms are not being built in a timely fashion, there's usually a reason. There may be problems with the new source, distribution patches that need to be ported (which you will lose building from pristine source), resource conflicts (both human and software), etc.

If you want to speed the deployment of an updated binary for your distribution, get involved with the development/QA/testing/documentation team to alleviate the hold-up.

I echo macemoneta's advice of doing your best to maintain your rpm based system using rpm's. This will keep your rpm database up to date with what is on your system. What distribution are you on and is there a package manager like yum or apt available that might do this all a lot easier? If not, you can try the src rpm method provided the newer release doesn't ask for other software not on your system.

I've done several packages, both older and newer versions this way with positive and negative results. Meaning sometimes it worked and other times it didn't mainly because of software incompatibilities.

The way I like to do this is put the src.rpm in the SRPMS directory of the rpm build area. This is /usr/src/redhat on Fedora and RedHat systems. Then install the src.rpm using rpm -ivh mynewsoftware.src.rpm. This puts the source and spec files out there in SOURCES and SPECS directories. Next head over to the SPECS directory where you'll see something like mynewsoftware.spec. To build the rpm you issue the rpmbuild -ba mynewsoftware.spec and cross your fingers. At this point it will build a new rpm and place it in the RPMS directory under one of the architecture subdirectories. You'll then be able to use that rpm just like the others delivered with your distribution. Just to be complete, the BUILD directory is where the source files get untarred and where the ./configure and make steps are performed.

Bill

I have Mandriva LE 2006... and files that I have needed have not been updated.

GTKPod for my iPod, QDVDAuthor, Kino... they all have very out of date pieces in the repositories. Even some tools are out of date, like dvdauthor, mjpegtools, qt...

Different distributions have different goals. Presumably you selected Mandriva because it provides greater stability and reduced maintenance over leading edge distributions (like Fedora Core). If that's not what you are looking for, select a different distribution.

If you only want to update a few packages, you need to establish the necessary development environment. You may need to install a dozen or more development packages simply to be able to rebuild a source file. Which packages you need are a function of the package you want to build.

That said, there are many ways to build a source file, with different goals in mind. On an rpm based distribution, you want to build a binary rpm, so that you can install the file as usual, using yum or the rpm command itself.

Building from source is not trivial, except for trivial software. Being able to recognize problems and correct from them, recovering from bad builds/installations, and dealing with new problems that don't (yet) have fixes are beyond what most folks want to deal with.

The best recommendation I can give you, is to find a distribution that meets your needs.

Thank you all for the responses. Most of the software for video and audio I have come up across just isn't being updated by Mandriva or its' supporters... however, its' simplicity of administration is so attractive, I just don't want to lose that. I'd say I have had to build about 10 pieces of software, and its' libraries to do what I am looking for. That being said, I am not an upgrader by nature... if it works, I stick with it.

Wine wasn't being updated at all for a long time, so I had to build it. GTKPod, Kino, QDVDAuthor... all the same story. Those are the ones I use the most. With its' dependencies, I always installed the rpm development packages they needed, unless there was a problem with that. Only a few of my packages weren't good enough, so I had to build them.

Luckily, most, if not all the software I installed is indepedent; it doesn't affect other software. I always installed into /usr just like the outdated rpm did. If the rpms catch up, I could risk it and install over my installation... or just leave things as is (which is what I will do).

If I run into these situations again, I will build my own rpms

Thank you so much for clearing up these questions. I just assumed most people had to compile and build a few programs and would have this problem... all of the beginner books have a few pages on how to build a program, and make it sound as if it is just as normal as installing an rpm...