Well thats probably more to do with the smart dependency system inherent in the ebuild/portage system, as well as compiling agains libraries actually on your system.
what you say about library problems being solved if you stick to the manufacturers's libraries and packages is pretty right, but once you want a package that (say) redhat doesn't stock, and it needs the latest version of another library, you run into problems. also if you try to install (say) a suse rpm on (say) a redhat machine, you might find that the suse rpm is compiled against a different library version, stuffing things up. gentoo pretty much fixes those sort of problems. when you compile app foo against library bar, it compiles against the version on your machine. If it needs a newer version of library bar, it compiles and installs that first. If you need version 1.8 AND 2.1 of the bar libraries to accomodate legacy programs that will only run against vers 1.x and new programs that run against 2.x, it uses "slots" - which is another way of saying that two versions of the same package can co-exist (in this case maybe called slot "1.8" and slot "2.x" In fact when kde 3.1 was released for gentoo, it shoved 3.1 in a different slot to 3.05, and therefore the two co-existed, enabling you to make sure 3.1 was going right before deleting 3.05a. clear as mud? On Thu, 13 Feb 2003 09:57:51 +1300 Gareth Williams <[EMAIL PROTECTED]> wrote: > but could you please > explain the reasoning behind "library dependencies just go away"? -- Nick Rout <[EMAIL PROTECTED]>
