http://defect.opensolaris.org/bz/show_bug.cgi?id=8334
--- Comment #3 from James Carlson <james.d.carlson at sun.com> 2009-05-05 05:26:26 --- (In reply to comment #1) > After reading /ws/onnv-gate/usr/src/lib/README.mapfiles, which discusses > Mapfiles and versioning in ON, I think the right answer is to bump the > SUNWprivate version number. So the phase 0.5 library is SUNWprivate_1.1, > and the new phase 1 library will be SUNWprivate_1.2. The numbering is a > bit unfortunate, but the initial mapping of 0.5 to 1.1 can't be changed, > so I'm not sure we can avoid some amount of numeric confusion. I'm not sure you need to do that. Presumably, the new libnwam will support only 1.2 and not the older 1.1 interfaces, correct? This also means that the old nwam-manager binary can't run with the new library, and the new binary can't run with the old library. And it likely also means that different symbols (function names) are being used. And it means that you've got a definite flag day for ON BFU users. In that case, I'd do nothing. A normal system upgrade will make sure that the right binaries are installed, as is true for all other library changes. If someone hacks his system to upgrade one part without the other (such as with BFU and forgetting the JDS component), then the symbol incompatibilities will cause it to fail to run, and you won't need the versioning. The only reason we've provided libnwam compatibility interfaces in the past was because it was possible to do so. In this case, since (as I'm assuming) you're not providing any 1.1 compatibility, I don't think there's a good reason to change the library versioning. If you do provide 1.1 as well, then adding 1.2 makes sense. -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
