> > So do I just create a symlink from yumgroups.xml which=20 > resolves to comps.xml ? >=20 > if this is in your own repository, yes. Excellent. :) > > Upgraded one system, no probs. rpm didn't like it on the=20 > other system. =20 > > 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. > look at rpm 4.2-1 > seriously. >From Fedora's site, correct? Is this a recommendation for all versions = of RHL from 7.2 to 9? 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. ;) 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? 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.) 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...." ;) jc > -sv >=20 >=20 >=20
