NB: Reply-To set to divert this thread over to install-discuss, as per jek3's earlier email. For the broken-MUA afflicted (mutt, etc..), please honour manually ;).
On Thu, 22 Mar 2007, Ed Gould wrote: > Paul Jakma wrote: > The RPM tools do this horribly badly. They always list the > dependencies as the selection of things present when the RPM was > built. This forces the admin to upgrade things outside the realm of > what they were trying to install, because the build machine was newer > than the install machine. Hmm, in what way? > The only way to get this right is to manually list the lowest version > of each dependency. It just doesn't work, for a large number of > reasons. Two of them are human error (how does one manually find all > the dependencies?) and test matrix explosion (I now have to test the > cross product of all version combinations). Hmm, but, imagine some library, library X, of which there are several updates that may be present on a machine. The soname and version symbols however remain the same. Application Y depends on it, by soname, perhaps by version symbols additionally. Why should Y (the project team say) have to look behind the curtain of the interface? If the library offers the soname+versions, then it meets the dependency. If there are problems, it's a regression in the library and should be dealt with as such (fix it and update). What's the problem exactly? That the customer has no way of knowing that library X has an update which is required to make Y work? (That potentially could be dealt with by having a 'pull up' reverse dependency, whereby the X update (X being required by Y) lists that Y regards, -- Paul Jakma, Solaris Networking http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190
