> Date: Wed, 16 Jan 2008 14:36:53 -0800 (PST) > From: David.Comay at Sun.COM ... > > >> Upon rereading PSARC 2007/047 though, you're correct that it's focused > >> on the naming conflict instead of other sorts of conflicts. Assuming > >> these libraries are Project Private (note that the opinion for the > >> Quagga case, PSARC 2005/57, is missing so I'm not sure of the stability > >> level here), would a reasonable solution here be to instead deliver > >> those components under /usr/lib/quagga? Private? > > > > No. I want to see them in /usr/lib, or a clear explanation of why > > they can't be there. As best I can tell, they belong there just as > > much as any of the GNOME bits. > > > > The reason I think it's important is that Quagga offers interfaces for > > new protocols to be built on top. Hiding these libraries in a > > non-standard location just makes us different from other platforms for > > no reason, and sets us up for the same kind of mess that /usr/sfw > > created. > > So these libraries do deliver public interfaces and the creation of new > protocols can be done outside of the Quagga project?
Paul Jakma, who initially integrated quagga, had mentioned it's possible the libraries are being used by some applications (we don't know which, if any), hence the need for symlinks from /usr/sfw/lib/lib* to the new location. The interface stability of the quagga interfaces should probably be Volatile, not Private. > > > We've been trying to do away with that problem. > > Again, you won't get any pushback from me on this in the general case. > If /usr/lib is where everyone else delivers the libraries, then that's > what I'd like to see at some point. But from a practical point of > view, I do see a difference between a library exporting public > interfaces and those which implement project implementation details. > > dsc
