On Mon, Mar 17, 2008 at 04:32:46PM -0500, Nicolas Williams wrote: > > Well... > > While working on the SQLite3 integration into SFW Mike Sullivan > requested that a heads up be sent to the w-team just in case there are > library name conflicts elsewhere. Mike (Sullivan) went so far as to > assert that we should do this when we add any libraries where other > software might pick it up. It's not enough to install the WOS and see > that there's not conflict because auto-configured items in, say, SFW, > might incorrectly think that your new library is something they should > use. > > I'm not sure how likely that is though. For example, there are two > things in SFW (Apache2 modules) that can use SQLite3, but won't use it > unless you add --with-sqlite3=... to the ./configure command line. > > But it's always possible that conflicts of this sort will arise. > > If we had tighter control over the Solaris library namespace then this > might not be an issue, but such control would imply more process for > folks integrating new libraries. There's a price to pay either. > > Finally, if there is a FOSS libscsi that predates ours and their ABIs > are different (which, unless we're doing a re-write, they will be) then > it would probably be better to avoid the conflict. The problem with > this is that having to search freshmeat.net, sourceforge, etc..., gauge > popularity/deployment of any conflicts found, and so on means that the > Solaris library namespace has exploded and there is no more control. > > Which brings me to the frightening possibility that anyone integrating a > new library into /usr/lib in Solaris would have to build and test *all* > the Solaris consolidations. Yes, Mike (Sullivan) almost went as far as > requiring that I do just that, but settled on requiring that I build > SFWNV and ONNV and send a heads up to the w-team and the JDS team. > > I would rather we avoid such a namespace explosion, but I'm not sure we > can, in the long-term anyways. >
This case does not introduce any library into /usr/lib, only into /usr/lib/scsi. - Eric -- Eric Schrock, Fishworks http://blogs.sun.com/eschrock
