> The issue has been thought about and wrote about in > great detail. I > would refer you, in particular, to Bart's excellent > overview of > dependency resolution and the problems faced with it: > > http://blogs.sun.com/barts/entry/satisfaction
That's because Mr. Smaalders chose to try to solve a problem which had already been solved, by engineers at sgi, almost twenty years prior! You (plural) have unnecessarily complicated the issue. All you had to do was tack a 128-bit steadily increasing integer to every subproduct (subsytem, subpackage, package), and simply automatically increase the serial number come new revision. The software management subsystem only has to check whether the serial number is higher than that of the product installed on the system, and if it is, the product is automatically marked for upgrade. And if you wanted to be really, really fancy, where you want a third party to be able to upgrade YOUR package and then have THEIR package be upgraded whenever SUNW issues a newer revision, all you had to do was add namespaces to the serial numbers. This, by the way, is how inst(1M) in sgi IRIX solved that problem. Like I wrote above, almost twenty years prior! SAT solver, while being a very clever solution, is also a misleading one, because it is only a partial solution, and is also neither a complete, nor the BEST solution to the problem Mr. Smaalders is trying to solve. > If a package says that it needs dependencies a, b, > and c. Then it has > claimed that it cannot work correctly without those > dependencies. So > when testing, you are verifying the existing > definition. Not saying that my modus operandi is correct in this instance, but I'm used to the FREEDOM OF CHOICE to disregard dependencies when I test a specific package's installation or removal, because not all dependencies are immediate. In fact, a lot of them a purely logical, so they are non-critical to package installation and removal. Things have not been thought through. And claims to the contrary are bad for IPS in the long run. -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
