On 23 Apr 2003, seth vidal wrote: > > > > 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. concur -- being able to cleanly replicate this sounds hard. The history | grep rpm posted a day or two ago indicated some unfamiliarity with the rpm query 'subject arguments' and RHL package names. I would speculate on ctrl-C, kill -9, --nodeps and --force as contributory factors as well. > > > 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 I part slightly from Seth here -- for production application, I trust content signed by Red Hat, and content Owl River packages, builds and signs for commercial customers for commercial applications -- I was lunching with a regional Linux engineer from IBM at lunch today, and he was surprised that I was not running the'latest and greatest' everywhere. To the contrary, I am quite conservative on 'updating' -- boring and stable is fine by me. > > 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. Owl River will provide a non-Red Hat maintenance admin and path for arbitrary Linux and *nix systems -- but it can get expensive when the customer will not leave production systems under professional management. Also in any human endeavor, there are unanticipated 'corners' from time to time, and Seth is too modest -- he has build a wonderful 'bridge' ont of sticky corners with 'yum' > > 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. local mirrors almost always make sense for cacheing. Choosing what to let into those mirrors is harder. <smile> > > 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. http://www.rpm.org/ Maximum RPM, and the mailing lists therein. I've 'smit'ted, pkgtool'ed, swinstalled, tarballed, dselcted, apt'ed, autorpm'ed, and autoupdat'ed [sorry, HUnter -- haven't 'current'ed']; 'yum' and RPM permit one to admin with amazing consistency and quality of result. -- Russ Herrold see: http://www.owlriver.com/support/ for commercial offerings.
