http://defect.opensolaris.org/bz/show_bug.cgi?id=8334
--- Comment #4 from Renee Danson <renee.danson at sun.com> 2009-05-05 10:31:57 --- (In reply to comment #3) > (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. Yes in both cases. > 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. Definitely. > 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. Hmm. This does sound reasonable. The README.mapfiles file has a section on "Adding a Private Interface"; it first says this: If the library already has Private interfaces, they may have numbered version names like SUNWprivate_m.n (due to errors of the past). If so, just use the highest numbered private version name to version the new interface. There is no need to introduce a new private version name. ...which would suggest that your "do nothing" answer is correct. However, the next paragraph says: There are libraries in the OSnet consolidation that contain only private interfaces. In such libraries, the SUNWprivate_m.n may be incremented to ensure that the programs that depend on them are built and delivered as a integrated unit. A notable example of this is libld.so (usr/src/cmd/sgs/libld), which contains the implementation of the link-editor, the public interface to which is provided by the ld command. When making a modification to the interface of such a library, you should follow the convention already in place. ...which somewhat muddies things. It was based on this paragraph (and the fact that Darren, who's responsible for libnwam's non-ON consumer, had asked about versioning) that I chose to change 1.1 to 1.2. > 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. Hmm. I'd looked at it differently: the versioning was important precisely because the new interface is incompatible. We wanted to make this change clear by updating the version number. But I'm no expert on this; if folks agree that not changing the version is okay, I'm perfectly willing to do so. -- 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.
