a b writes: > And that includes packaging and maintaining 3rd party software for Solaris > by 3rd party developers. > > For example, I've been churning over delivering just patches as > fixes/overlays on top of my own packages for Solaris -- it's not about > patching the OS, it's about patching 3rd party software here.
For 3rd party software, I'd say that you're on your own to determine what you need to do in order to support your customers. If your customers do not want to see new features in patches, then make sure you don't deliver them that way. If they do, then arrange to make it happen. Solaris can't (and doesn't) make that determination for you. > And to deliver software correctly, one must understand how things are > packaged and why. One must understand when to deliver a new package > revision, and when to patch; what should be delivered as a patch, and what > as a new package. After all those are architectural decisions. Agreed, but they're not necessarily relevant architectural details *outside* of the domain in which they're used. In other words, the fact that Sun delivers new features in patches doesn't normally affect existing software. In fact, our architectural reviews address exactly that issue and we don't normally allow conflicts into patches. If what you're trying to assert here is that third party packages should develop Rosetta stone encodings mapping patch IDs to features, and thus depend on this delivery detail of Solaris, then I strongly disagree. That's an extremely unwise thing to do, because we do _not_ document the patch stream itself as an interface on which you can depend. The believe right answer for software like that is to use feature-based tests. In other words, if you know that you need Feature X in order to make your software work, then test directly for that when you install or run -- try to use the feature, and tell the user about the problem if it's not there. Basing that test on some artifact of the system construction (such as patch IDs or version numbers) is just asking for trouble. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
