On Fri, Oct 26, 2007 at 02:50:35PM -0500, Les Mikesell wrote: > Nor is there much reason to think it could fix your problem of trying to > install packages that weren't built to be installed together. There > aren't a lot of conflicting conary packages in the wild yet. Quite right. I was primarily answering Tim's query: > I'd have to wonder why you'd want to do that. You might as well do > Linux from scratch, or pick on of the other smaller distros which don't > use a package manager. Yum works reasonably well these days, and the underlying RPM infrastructure is improving. But it is really designed to function on one machine at a time. It is hopelessly broken when attempting to maintain a collection of instances (physical or virtual) e.g., laptop-, workstation-, server-, and appliance-class installs differing in whether they have X11, -devel packages, -debuginfo packages, etc., especially when one would like to have some things, like documentation and debuginfo files, on shared storage. The packaging mechanism also makes it inordinately difficult to apply and maintain local changes; e.g., at our firm, we maintain fairly trivial changes to kernel, initscripts, openssh, etc., that have been rejected upstream. Rather than a five-line change that says "whenever installing package foo, merge these patches or build changes (e.g., --enable-*) to upstream source (now and for all time) and dump the compiled packages in my local (preferred) repo branch," we end up hacking spec files manually or with ad-hoc scripting. It's idiotic, and avoiding the headache requires writing a whole bunch of python or perl to parse and modify spec files. :-/ Bill
