Paul Jakma wrote:
> On Thu, 22 Mar 2007, Ed Gould 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?
See below.
>> 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
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.)
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.
--
--Ed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ed.gould.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/install-discuss/attachments/20070322/3cc70cad/attachment.vcf>
