[lug] Managing RPMs
Kenneth D. Weinert
kenw at quarter-flash.com
Tue Mar 2 09:09:59 MST 2010
Or, perhaps more correctly, managing a system.
Here's my issue with a bit of background.
Over time here at work we've gotten into a real mess with knowing which
programs are actually being run. Over time we've tried different schemes
to ensure that the latest stuff is being run.
We have directory paths with /dev/ /stage/ or /prod/ in them. They can
have machine type as well (Linux-i686, SunOS-i86pc, etc) They're almost
always NFS mounted paths as that was thought to make it easier (update
once, update everywhere.) At one point we changed the name of the root
of this shared FS to ensure that everyone was using the right one.
As you have probably guessed by now this hasn't exactly worked out the
best in the long run. We have some production config paths that have
/dev/ in them, we still find old config files that have the old path in
them, etc.
So, for this latest incarnation, since I have to rewrite all the tools
anyhow (new library, completely incompatible) I want to fix all that up.
So I'm using RPMs for installing, not using a shared filesystem, want to
set up local repositories, etc.
Now that you've some background, here's the meat of the problem. I have
a library installed on the system, version 1.1.0. I now have an update,
2.0.0 and when I try to RPM install it I run in to an issue (or two).
If I try rpm -U then I get complaints about all the other programs that
still depend on the currently installed 1.1.0. rpm -i gives me messages
about conflicts on the header files (which, of course, don't have
version numbers associated with them.)
It doesn't help that currently this is both a development and testing
box (initial testing - and yes, I already know this is insanity, but I'm
not the one that can change that and my boss doesn't seem to see the issue.)
At any rate, I'm completely sure that I'm not the first person to run in
to the issue where I have to update the libraries on a system so I can
create new RPMs for the programs that depend on those libraries and
update them on the system as well.
Any pointers to managing a system like this will be *greatly* appreciated.
Ken
More information about the LUG
mailing list