Geir Magnusson Jr. wrote: > > I believe that the dependency chain is 'self cleaning' as it's version > specific (notation A:X -> package:version ). With something simple : > > A:X depends on B:Y and C:Z > > Now, I assume that since the developer states the above as true, it was > tested, and any implied dependency chains extending from B:Y and C:Z also > work together, else the above statement about A, B and C isn't true. (Or it > wasn't tested as such.) > > I know that this appears to be trivial - however, I think it isn't. Lots of > problems get solved by recognizing this. Not all, but lots.
If you hadn't noticed, the release manager for "A" probably created a simple download that contains A:X, B:Y, C:Z, and the recursive closure of the dependencies. A single download, and unpack, and I'm likely up and running - as long a "A" is all that I need. Life gets interesting when you ask questions like "will Tomcat 4.0 work with Cocoon 2.0". Neither package contains the other. The release maanger for Tomcat 4.0 includes a recent, released version of crimson.jar. The release manager for Cocoon 2.0 includes a recent, released version of xerces.jar. Boom. All of Criag's efforts, and he could not get the isolation that a web app is supposed to provide to reconcile this situation. Tomcat 4.0.1 ships Xerces. = = = = Velocity depends on commons-collections. Tomcat-4.0 does too. Velocity does not depend on Tomcat. Tomcat does not depend on Velocity. User often want to run them both together. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
