David.Comay at Sun.COM writes: > > Instead, it's *only* for naming conflicts -- cases where there's a GNU > > variant of some utility (e.g., tar) where a user would want to have an > > un-prefixed alternative by setting his path. > > > > Furthermore, we have GPL all over the system, not just here, and a lot > > of it is in /usr/lib. What could make this one project special? > > It's my understanding that those GPL components under /usr/lib should > not be there per the most recent guidelines from Sun legal. So it was > my recommendation to the team to explore the alternative of > /usr/gnu/lib as Quagga is one of the GNU components in the FSF/UNESCO > Free Software Directory.
Something's going awry here, as a "closed approved automatic" case should not be the place for Sun's legal group to set new architectural policy for the system. I know of no practical reason to segregate GNU bits into a special ghetto. Just about all of GNOME is under GPLv2 or LGPL, and we intentionally don't do any separation with those, and I don't see why Quagga is being subjected to a different set of rules. Nor, frankly, do I see what establishing such a ghetto would accomplish. If you need one, /usr/sfw is already a mess like that. > 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. We've been trying to do away with that problem. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
