[lug] Managing RPMs
Jeffrey Haemer
jeffrey.haemer at gmail.com
Tue Mar 2 16:01:14 MST 2010
Ken,
I bought "Managing RPM-Based Systems with Kickstart and
Yum"<http://oreilly.com/catalog/9780596513825>,
by Quin McCallum, for $10. Even my tight-fisted CFO was willing to part
with a sawbuck.
My distro didn't exactly map to his, just like your problem won't map
exactly onto mine (they never do, do they?), but the pamphlet is way more
than ten bucks' worth of help.
I followed McCallum's instructions, set up a yum server, and we now shovel
locally-built RPMs into a local, yum repo. Engineers here now do "yum
install" and "yum update," instead of mis-typing raw, rpm commands.
Sometimes, this even handles annoying version changes.
HTH.
On Tue, Mar 2, 2010 at 9:09 AM, Kenneth D. Weinert
<kenw at quarter-flash.com>wrote:
> 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
> _______________________________________________
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
--
Click to Call Me Now! --
http://seejeffrun.blogspot.com/2009/09/call-me-now.html
Jeffrey Haemer <jeffrey.haemer at gmail.com>
720-837-8908 [cell], @goyishekop [twitter]
http://www.youtube.com/user/goyishekop [vlog]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20100302/f831be29/attachment.html>
More information about the LUG
mailing list