> > > Upgraded one system, no probs. rpm didn't like it on the > > other system. > > > Now doing an "rpm --rebuilddb". Argh. > > Turns out not even a --rebuilddb would fix the problem. Couldn't see any other rpm process running. Ended up rebooting, which cleared the problem. odd odd. > >From Fedora's site, correct? Is this a recommendation for all versions of RHL from 7.2 to 9? oh no no no. rhl 7.1-7.3 have rpm 4.0.4 and should stay there imo. 8.0 would need rpm 4.1.1 and 9 rpm 4.2-1 > 1) Will this likely cause future dependency problems as rpm evolves on > the RH side of things? In other words, if I were to implement your > recommendation, is there any chance that 6-12 months from now, I'll be > wondering how I managed to paint myself into a corner? (Feel free to > add management-friendly buzzwords. ;) not obvious to me. You'll need to talk to people at red hat. I'd doubt it. > > 2) Assuming that rpm-4.2-1 is The Way To Go, then ideally I would set > it up on our apt/yum repository locally. (I suspect that the Better > Way would be to tweak yum.conf and sources.list to include fedora.us, > but that doesn't really help us optimize WAN traffic as the number of > machines which use apt/yum grows. Hence the local repository.) Given > that, I imagine I should create an RPMS.misc directory for these > one-offs. Or? Is there a better approach? fedora allows you to mirror all of their content which would reduce your traffic b/c you'd only be transferring the changed bits once :) go talk to warren togami about it. He's the guy leading things over there. > 3) I take it that by merely adding the path/repository to yum.conf > (and to sources.list, for the apt folks), that yum (apt-get) will be > able to determine that the fedora.us version of rpm is 'preferred', > for lack of a better term...? (I think I'm showing my ignorance of > the capabilities of rpm here.) it's all up the version of the rpm - or if you pkgpolicy=last - what order your repositories are in your yum.conf > 4) I suspect more questions are to follow. If you feel that I'm a > little weak in my understanding of rpm, could you direct me to an > appropriate primer? The RPM approach has shown me that it has > strengths over, say, Solaris' package manager. Package management in > general is preferable to just dropping a tarball into place today, > only to resist change in the future because, "... we don't know what > the upgrade will break...." ;) You're definitely on the right track. go to rpm.org and get some ideas. Ask on this list - the rpm.org maintainer russ herrold is on here and I think he is around to answer questions about things from time to time. we've been using rpm for distro maintenance at duke for a good while now. and I know a lot of folks on this list are doing a lot of good things with rpm on various platforms and distros. -sv
