RPM Dependencies vs Source
 

Okay - I've been around for a while - so I'm not a totally newbie - but I do have a newbie question that has perplexed me for quite a while, regarding those annoying RPMs ...

I'll use my new install that I'm trying to perform for an example.. RH 7.2 .. and just as an experiement basically, I'm trying to upgrade everything through RPMs ... At this point, I've updated everything through RedHat's up2date program, which brings "most" of everything up-to-date, but not quite. I upgraded to kernel version 2.4.17 through an RPM ... and so far have been stopped there.

Right now I thought I'd work on upgrading GCC (since 2.96 sucks) and XFree86. Okay, I *know* I can upgrade these no problem via source.. but I want to do this through an RPM (don't ask me why, I'm just being anal, so deal with it :D ) .. as I guessed, I get a freakin slew of dependencies from the start .. same thing with both programs.

Some of these say "conflicts" and others say things are the wrong version and others say stuff is missing. This just seems like an *act of god* must be approved before something can be upgraded via an RPM .. I'm not about to write down this screen full of crap and goto rpmfind.net and try to hunt down all this junk. So I guess my question is.... or statement..... what am I missing here, is the RPM idea just a load of crap or what? Half of these dependencies I'm seeing are load of (you guessed it) crap, and others are a catch-22 or something I just laugh at and point.. :D

But if I just go to source and install everything that way, I basically break the hell out of my current RPM database, because I've bypassed it entirely.

What's the best way to do this .. what am I missing here...? At this point I'm totally confused as to how to go about this the *proper* way... I'm pretty anal when it comes to production systems and everything being neat and orderly - so this isn't a question for you guys that just slap stick something together and smile because it works... no offense to anyone.

Any discussion is appreciated, as I'm totally confused.

-Aragorn

I might not be the right one to answer the question. But in my opinion you should eaither stick to RPM's or go source code install pretty much all the way. It's when you start mixing the two that you run into big problems. I never really got into using the RPM system to it's fullest. I basically hated it from the start because it never did exactly what I wanted. It does seem to be simple for small applications. But once you start playing around with vital components with rpm's is when you run into dependency nightmare. Especially if you installed one of the libraries from source and the rest from RPM.
I'm still working on totally redoing all my systems to LFS and everything is strictly source on there. I like it a lot better so far.
I think the more popular distributions have tools which handle the searching for all the rpm's you need. I know Mandrake had something like that. It gave a big list of all the additional packages it needed and asks if you want to install all those too.

Yeah, that's called URPMI. It's OK, but it doesn't really deal with the problem of almost-broken dependencies caused by using source.

I think a util (or cron job) that searches through your hdd(s) for libraries and adds them to the local RPM database would make life so much easier for people (like me) who use both RPM, URPMI and source. Perhaps it could be run either at a set time (4:26am, every Tuesday?) or when processes drop to below a threshold load.

You can run a rpm command (sorry not at my Linux box at the moment) that updates the database only - check 'man rpm' for the command. So you can add stuff using source, then update the database as if you had used the rpm method.

This dependencies thing is supposed to ensure you have a stable system - so it stops you deleting something your system would need - and makes sure you install everything you need to run a package. It does depend on how good a package builder is, but generally I would say think about those messages before you give up on it.

If you are upgrading an old system, you will have to upgrade a lot of libraries, etc. which give you problems - the kernel and glibc are pretty much like giving you system a brain and heart transplant. There are instructions available for how to do this.

Joe

But would you really trust someone who has only read the 'instructions' to do a heart transplant?

Yea I've attempted a GLIBC recompile before.. Never did that that to work right, it always broke everything. But that's another story.

Yea, I think an LFS is probably my answer.. I've been to the web site and kinda looked things over, and it doesn't seem to difficuilt in my opinon from just reading things.. but the only question I could never find on an LFS system, is how to get the thing started. If I have a new blank hard drive/system - and want to start an LFS system .... hoooow do I get started.. what is already built to setup the partitions, format them and get a base installed so I can start installing programs and such... I never really found an answer to this anywhere.

Maybe you guys can give me some tips on how to START the LFS, in order to get me to that point of installing everything from source.

Thanks for the responses -

Aragorn

Go here http://linuxfromscratch.org/ if you haven't already. To start creating an lfs system you need to have linux installed first. You use the installed linux to compile your lfs until you get far enough along to use the lfs itself to compile the rest of it.

hi ryanstrayer. how's tricks?

Actually, most RPM source packages have a make file that will create a binary RPM after the compile (if they don't, they should have; but that is another thread). I would suggest that if you want to use sources, that you do the following steps to keep everything in sync.

Get the source RPM,
Build it,
Create a new binary RPM from the compiled source
Install the binary RPM

If the binary install says there are dependencies, use the same steps for them. This way your data base stays up-to-date.

Manually updating the data base is also a goog way to solve this problem, but I'm too lazy to do it that way.