On Thu, 22 Mar 2007, Ed Gould wrote: > The problem is illustrated by this scenario: Application A and > application B both depend on library L. Version 1 of each of A, B, > and L are installed. The admin wants to upgrade A to version 2. A.2 > can run perfectly well with L.1, but the machine on which the package > for A.2 was built had L.2 installed, and L.2 includes an interface > change that is not compatible with B.1. So updating A to A.2 drags in > L.2, even though it didn't really need to. This either breaks B or > requires it to be updated, too. If updating A is required and > updating B is not allowed, what's the admin to do? (The "update A but > not B" requirement is not uncommon.)
Right, that's a problem, I'm not sure it'd be RPMs (or whichever package managers) fault though. E.g., presuming RPM snarfed the dependency by way of version symbols, well that was the linkers choice to make the application depend on the newer/incompatible symbols rather than the older/compatible ones ;). Otherwise, there's nothing RPM can do - it's either an error (or a /concious/ choice perhaps, for sounds reasons) on the software packagers side. > Of course, one can often work around a small set of problems like this > example. But when the dependency list - with all the sub-dependencies > - is many hundreds of items long, it can make the update of one simple > piece into an update of most of the system. It may not even be > possible to learn what the extent of the problem is without > iteratively downloading hundreds of megabytes of updates. Surely this is intrinsic to the dependencies that exist within modern software systems, and the management thereof a general problem? The technical minutia of choices made by any one package management system are another matter, and don't change the fact we face the same problems. That we avoid the problems other systems (RPM/Fedora, Deb/Debian) may have is simply due to the fact that have no way to have /any/ selective dependency-driven updates[1]. By avoiding the problems, we also avoid the advantages ;). 1. Other than patches.. regards, -- Paul Jakma, Solaris Networking http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190
